HTTP통신 깊게 알아보기

HTTP란? 

HTTP는 HyperText Transfer Protocol의 줄임말로

 

웹환경에서 정보를 주고받는 의사소통의 규칙 및 약속이며 데이터 전송에 TCP 프로토콜, 라우팅에 IP프로토콜을 사용하는 구조를 갖추고 있습니다.

 

※ HTTP는 주로 TCP를 사용하므로 TCP에 대한 이해가 필요합니다. 이글은 TCP에 대한 자세한 설명은 생략하므로

     아래 링크를 참고해주세요.

     https://developer111.tistory.com/100

 

HTTP 버전별 특징

HTTP/0.9

• GET /mypage.html (원라인 프로토콜)
  - 메서드는 GET만 존재하며 요청은 단 한줄로 이루어짐
• 응답은 HTML문서만 제공
• 헤더 없음

HTTP/1.0

• 헤더(http버전 정보, 상태코드, Content-type 등) 추가
  - 상태코드를 통해 오류파악 및 처리가 용이해짐
  - Content-type을 통해 html외의 파일 전송 가능해짐

HTTP/1.1

• Persistent Connection
• 파이프라이닝
  - head of Blocking 문제
  - 연속된 요청 헤더 중복

 

http 버전별 '요청-응답' 처리 과정

HTTP/1.0	HTTP/1.1 (Persistent Connection)	HTTP/1.1 (PipeLining)
- 요청과 응답에 대해 매번 커넥션     연결과 종료를 해야함	- 일정 시간 내에 들어온 요청에 대해     커넥션 유지하여 사용 - 매 요청 커넥션을 연결하고 종료하지    않으므로 latency를 줄임	- 이전 방식과 다르게 '요청-응답'을     반복하지 않고 요청을 여러개     보내고 응답을 받을 수 있음  - 응답은 반드시 요청 순서대로 전송

 

But, 여전히 해결되지 않은 문제 Head Of Line Blocking

PipeLining 방식에서 요청 순서대로 응답되므로 특정 요청의 응답 처리시간이 길어진다면 다음 응답들도 모두 대기 후 전송됩니다.

1번 요청이 10초, 2번과 3번 요청이 1초만에 처리되어 응답을 보낼수 있어도 2, 3번 응답은 10초를 대기하고 응답을 전송하게 됩니다.

 

이러한 현상을 Head of Line Blocking이라고 합니다.

 

HTTP/2.0

Multiplexing                 

• 멀티플레싱
  - HTTP 메시지 전송방식에 바이너리 프레임을 사용하여 요청순서에 무관하게 데이터 처리
     => Head of Line Blocking 해결
     

<바이너리 프레임 구조>

           기존 HTTP 메시지는 헤더정보와 바디정보가 한줄  띄는 방식으로 구분 되며 텍스트 형태였지만,
           HTTP2에서 메시지를 프레임으로 쪼개고 각 프레임은 Header , Data frame으로 구성되고 바이너리로 인코딩
           (바이너리 프레임은 중간에 끼어들 수 있으며 헤더정보를 통해 순서대로 조립 가능)

 

<TCP 연결상태에서 N개의 스트림 형태>

           HTTP/2에서 TCP에 복수개의 스트림을 생성하고 스트림 하나가 요청과 응답을 모두 처리할 수 있으며 

          복수개의 요청과 응답 또한 하나의 스트림에서 처리 할 수 있습니다.

          이전에는 순서대로 응답을 받아야 클라이언트가 사용할 수 있어 서버에서도 요청 순서대로 보냈지만

          이제는 바이너리 프레임을 통해 요청 순서상관없이 응답을 받아도 조립하여 사용할 수 있으므로

          서버에서도 처리되는대로 응답을 보냅니다. 

          또한 여려개의 병렬 스트림 구조로 하나의 TCP 커넥션 안에서 더 많은 요청과 응답을 처리할 수 있게되어

          이전보다 커넥션 연결, 종료에 대한 비용이 절감되었습니다.

 

• 서버푸시
  - 서버에서 클라이언트가 필요할 것 같은 정보를 미리파악하여 전달 가능
     (ex. html파일을 요청하면 서버에서 html파일에 사용되는 css, js파일을 함께 보냄 )
  
  
• 헤더 압축(중복 제거)
  - 이전 버전까지는 요청/응답마다 같은 헤더정보 또한 반복해서 전달해야 했지만 허프만 코드를 이용하는
     HPACK 알고리즘을 이용하여 헤더를 압축하여 전송했고 이로 인해 패킷 사이즈 감소

 

 

HTTP의 성질

- 비연결성(connectionless)

 

http통신은 클라이언트의 요청에 서버의 응답이 돌아오면 연결을 끊습니다.

 

즉, TCP 연결을 끊게 되는 것이고 요청을 할 때마다 새롭게 연결하는 것 입니다. 

 

HTTP/1.0 모델에서 요청과  응답마다 커넥션을 재연결하는 것이 바로 이런 특성입니다. 

 

HTTP/1.1에서 이러한 비효율성을 해결하기 위해 Persistent Connection 방식을 통해 

 

일정시간 동안 요청에 대해서는 하나의 커넥션 연결에서 모두 처리할 수 있게 개선이 된 것입니다.

 

- 무상태성(stateless)

 

서버는 사용자의 상태를 알 수 없습니다.  그렇기 때문에 사용자가 이전에 어떤 요청을 했는지 알 수 없습니다. 

 

예를 들어, 로그인을 했음에도 불구하고 로그인 정보가 남아 있지 않아 계속해서 로그인을 해야하는 상황이 일어납니다.

 

허나, 우리는 위와 같은 상황에 거의 직면한 적인 없습니다. 이는 세션-쿠키 또는 토큰 방식으로 

 

우리가 이전에 요청했던 사람이란걸 계속 알려주어 마치 서버가 클라이언트의 상태를 보존하는 것처럼 동작하게 합니다.

 

 

 

++++++ 참고+++++++++(추후 별도 포스팅 예정)

HTTP/3 (QUIC프로토콜)

전송계층에서 TCP 아닌 UDP기반의 QUIC 프로토콜 사용

HTTP/2.0에서 메시지를 바이너리 프레임으로 쪼개어 순서상관없이 응답을 받아도 상관없다고 하였지만, 이는 어디까지나 메세지 단위에서 순서라는 제약조건을 해결한 것이지 TCP계층의 패킷 단위에서는 여전히 순서라는 제약조건이 존재합니다. 
예를 들어 HTTP/2.0에서 여러개의 병렬 스트림에서 1번 스트림의 패킷이 유실되면 2~N번 스트림은 모두 대기상태에 있습니다.
즉, 전송계층에서 패킷단위로 본다면 여전히 Head Of Line Blocking이 존재합니다.
이로인해 TCP를 사용하지 않고 UDP를 사용한 QUIC프로토콜이 등장하게 되었습니다.