[Web] HTTP(Hyper Text Transfer Protocol) 알아보기

 

프로토콜: 컴퓨터들 간의 원활한 통신을 위해 지키기로 한 규약

프로토콜에는 HTTP, TCP, IP, SSH 등 여러 종류가 있다.

HTTP(Hyper Text Transfer Protocol)

: HTML 문서와 같은 리소스들을 가져올 수 있도록 해주는 프로토콜

HTTP 역사

1. HTTP /0.9 (Online Protocol)
   • GET 메소드만 존재, HTML 만 전달 가능한 매우 간단한 형태
2. HTTP /1.0
   • 헤더 부분 추가, 응답에 상태코드 추가
   • 응답 부분에 Content-Type가 생겨 HTML 외 다른 파일도 전송 가능
   • 1 Request & 1 Response Per Connection
     • 매번 새로운 연결로 성능 ⬇︎
     • 서버 부하 비용 ⬆︎
3. HTTP /1.1
   • Persistent Connection (지정한 timeout 동안 커넥션을 닫지 않는 방식) 도입
   • Pipelining 기법을 통해 요청-응답의 지연 시간을 축소시킴
4. HTTP /2.0 (2015년 도입)
   • 기존 HTTP /1.x 버전의 성능 향상에 초점을 맞춘 프로토콜 (표준의 대체가 아닌 확장)
   • HTTP 메시지 전송 방식의 변화
     • 바이너리 프레이밍 계층 사용 → 파싱, 전송 속도 ⬆︎ / 오류 발생 가능성 ⬇︎

HTTP 장단점

장점

불특정 다수를 대상으로 하는 서비스에 적합. 계속 서버와 클라이언트의 연결상태를 유지하는 것이 아니기 때문에 클라이언트와 서버간의 최대 연결수보다 훨씬 많은 수의 요청과 응답 처리 가능

단점

연결을 끊어버리기 때문에 클라이언트의 이전상황을 알 수 없음 → Stateless 상태

이런 Stateless 특징 때문에 Cookie와 같은 기술 등장

❊ Cookie: 서버를 대신에 웹 브라우저에 저장되어 있다가 요청 시에 정보를 서버에 전송해 사용자를 식별할 수 있음

HTTP 구조

1. Request (요청)

• Start line: HTTP request의 첫 라인
  • HTTP 메소드: 해당 request가 의도한 action을 정의하는 부분
  • Request target: 해당 request가 전송되는 목표 uri (예시) /login
  • HTTP Version
• Headers: 해당 request에 대한 추가 정보(addtional information)를 담고 있는 부분
  • Host: 요청이 전송되는 target의 host url (예시) google.com
  • User-Agent: 요청을 보내는 클라이언트의 대한 정보 (예시) 웹브라우저에 대한 정보
  • Accept: 해당 요청이 받을 수 있는 응답(response) 타입
  • Connection: 해당 요청이 끝난후에 클라이언트와 서버가 계속해서 네트워크 컨넥션을 유지 할것인지 아니면 끊을것인지에 대해 지시하는 부분
  • Content-Type: 해당 요청이 보내는 메세지 body의 타입 (예시) JSON을 보내면 application/json
  • Content-length: 메세지 body의 길이
• Body: 해당 request의 실제 메세지/내용
  • body가 없는 경우도 존재 (주로 GET 메소드)

2. Response (반환)

• Status line: Response의 상태를 간략하게 나타내주는 부분
  • HTTP Version
  • Stauts code: 응답 상태를 나타내는 코드
  • Status text: 응답 상태를 간략하게 설명해주는 부분
• Headers: 일부 header 값 제외하고 Response의 headers와 동일
  • User-Agent → Server
• Body: Response의 body와 일반적으로 동일

HTTP 상태 코드

• 1xx(정보) : 요청을 받았으며 프로세스를 계속 진행합니다.
• 2xx(성공) : 요청을 성공적으로 받았으며 인식했고 수용하였습니다.
• 3xx(리다이렉션) : 요청 완료를 위해 추가 작업 조치가 필요합니다.
• 4xx(클라이언트 오류) : 요청의 문법이 잘못되었거나 요청을 처리할 수 없습니다.
• 5xx(서버 오류) : 서버가 명백히 유효한 요청에 대한 충족을 실패했습니다.

HTTP 메소드

1. GET

GET은 쉽게 생각하면 DB에서 SELECT를 하는 개념이다.

클라이언트가 서버에 GET 요청을 보내게 되면 서버는 해당 값을 반환한다.

먼저 GET 요청 예시를 살펴보면, 다음과 같다.

<http://localhost:0000/login?id=minhyuk123&pw=1234>

다음과 같이 URL 뒤에 쿼리 파라미터가 직접적으로 드러나있는 것을 볼 수 있으며 이에 따라 여러 특징이 파생된다.

GET 특징

• URL 뒤에 쿼리 스트링을 드러낸 채로 서버에 전송
• 따라서 정보들이 그대로 노출되어 보안에 취약
• 캐싱 가능
• 전송하는 데이터 양에 제한이 있음(브라우저마다 상이)
• 브라우저의 히스토리에 기록이 남음
• POST 방식에 비해 속도가 빠름
• HTTP 메세지에 body가 존재하지 않음

※ 캐싱 : 해당 데이터를 다시 요청할 때 빠르게 반환하기 위해 레지스터에 데이터를 저장시켜 놓는 것

따라서 GET 요청은 조회와 같은 간단한 데이터 요청에 적합한 메소드이다.

 

2. POST

POST는 DB에서 CREATE 하는 개념이라고 생각할 수 있다.

클라이언트가 서버에 리소스를 생성 또는 수정하고자 할 때 POST 요청을 보내게 된다.

POST 요청 예시는 다음과 같다.

<http://localhost:0000/login>

GET 과 달리 URL 뒤에 쿼리 파라미터가 직접적으로 드러나있지 않다.

POST 특징

• URL 뒤에 쿼리 스트링이 노출되어 있지 않음
• 따라서 GET 방식에 비해 상대적으로 보안적임
• 캐싱 불가
• 전송하는 데이터 양에 제한 없음
• 브라우저 히스토리에 기록이 남지 않음
• GET 방식에 비해 속도가 느림
• HTTP 메세지에 body가 존재

POST 요청은 생성 또는 수정에 적합한 메소드이다.

추가적으로, GET과 POST 의 중요한 차이점 중 하나는 멱등성 유무이다.

멱등성이란 연산을 몇번 반복하더라도 결과가 달라지지 않는 성질을 말하는데,

GET은 리소스를 조회하므로 멱등성을 띠지만, POST는 요청할 때마다 리소스를 생성 또는 수정하므로 멱등성을 띠지 않는다.

 

3. PUT

PUT은 POST와 유사하지만, 리소스를 완전히 대체하고 해당 리소스가 없으면 생성한다.

POST와 가장 큰 차이점은 어떤 데이터가 존재하지 않으면 그 데이터를 포함시키지 않고 대체한다.

그래서 POST는 새로운 데이터를 계속 생성하기 때문에 요청시마다 데이터를 생성하지만, PUT은 사용자가 데이터를 지정하고 수정하는 것이기 때문에 같은 요청을 계속하더라도 데이터가 계속 생성되지는 않는다.

또 PUT은 리소스의 주소를 정확히 알고 있어야 한다.

 

4. DELETE

클라이언트에서 DELETE 요청을 보내면, 서버에서는 해당 리소스를 삭제한다.

 

---

본 게시글은 다음 영상들을 참고하여 작성했습니다. -<우아한테크코스 10분 테코톡>

https://www.youtube.com/watch?v=xcrjamphIp4&t=412s

https://www.youtube.com/watch?v=QcKEJFvPryI&t=314s