HTTP 더 알아보기

부록 : HTTP 더 알아보기

---

HTTP / 0.9 & HTTP / 1.0 한계

• 각 요청에 대해 새 커넥션을 열고 응답이 전송 된 직후 닫아야했다.
• 새 연결이 설정 될 때마다 TCP 3-way Handshake가 발생한다.
• 더 나은 성능을 위해서는 클라이언트와 서버 간의 왕복 시간을 줄이는 것이 중요했다.
• HTTP / 1.1은 지속적인 연결을 통해 이를 해결했다.

TCP 3-way Handshake란?

• TCP 장치들 사이에서 논리적인 접속을 성립하기 위하여 3-way Handshake를 사용하는데 3-way Handshake는
  TCP/IP 프로토콜을 이용해서 통신을 하는 응용프로그램이 데이터를 전송하기 전에 먼저 정확한 전송을 보장하기 위해
  상대방과 사전에 세션을 수립하는 과정을 의미한다.

  • 1. Client to Server: TCP SYN (Synchronize Sequence Numbers)
  • 2. Server to Client: TCP SYN + ACK(Acknowledgment)
  • 3. Client to Server: TCP ACK

  TCP 3-way Handshake 역할

• 양쪽 모두 데이터를 전송할 준비가 되었음을 보장하며, 실제로 데이터 전달이 시작하기전 한쪽이 다른쪽의 준비가 되었다는
  것을 알 수 있도록 한다.

• 양쪽 모두 상대편에 대한 초기 순차 일련번호를 얻을 수 있다.

  

  TCP 3-way Handshake 과정

• Step1: 클라이언트는 서버에 접속을 요청하는 SYN 패킷을 보낸다. 이때 클라이언트는 SYN을 보내고 SYN/ACK 응답을
  기다리는 SYN_SENT 상태에 돌입한다.

• Step2: 서버는 SYN 요청을 받고 클라이언트에게 요청을 수락한다는 ACK와 SYN Flag가 설정된 패킷을 발송하고
  클라이언트가 다시 ACK로 응답하기를 기다린다. 이떄 서버는 SYN_RECEIVED 상태가 된다.

• Step3: 클라이언트는 서버에게 ACK를 보낸 이후로 연결이 이루어지며 데이터가 오간다. 이때 서버 상태가 ESTABLISHED다.

TCP 4-way Handshake란?

• TCP 3-way Handshake이 TCP의 연결 초기화를 위해 사용했다면 (연결을 시작하려) TCP 4-way Handshake은
  세션을 종료하기 위해 수행되는 절차이다.

TCP 4-way Handshake 과정

• Step1: 클라이언트가 연결을 종료하겠다는 신호 FIN플래그를 전송한다.
• Step2: 서버는 확인 메시지를 보내고 자신의 통신이 끝날때까지 기다리는데 이 상태가 TIME_WAIT 상태이다.
• Step3: 서버가 통신이 끝났으면 연결이 종료되었다고 클라이언트에게 FIN플래그를 전송한다.
  • FIN을 전송하기 전 패킷이 라우팅 지연이나 패킷 유실로 인한 재전송 등으로 인해 FIN 패킷보다 늦게 도착하는 상황이
    발생한다면 클라이언트는 세션을 종료시킨 후 뒤늦게 도착한 패킷이 있다면 이 패킷을 Drop하고 데이터는 유실될텐데 이러한
    현상을 대비한 과정이 TIME_WAIT 이다.
• Step4: 클라이언트는 확인했다는 메시지를 보낸다.

HTTP / 1.1 동작방식

• HTTP/1.1은 기본적으로 커넥션당 하나의 요청을 처리하도록 설계 되어있다.

• 요청과 응답이 순차적으로 이루어지지만 동시 전송이 불가능하다.

  HTTP / 1.1 한계

  • 동시전송이 불가능하다.
  • HTTP 문서안에 포함된 다수의 리소스를 처리하려면 요청할 리소스 개수에 비례해서 대기시간(Latency)이 길어진다.
  • HTTP의 HOL(Head Of Line) Blocking (특정 응답의 지연)
    • HTTP/1.1의 커넥션당 하나의 요청처리를 개선하는 기법중 파이프라이닝(Pipelining)이 존재한다. 이것은 하나의
      커넥션을 통해서 큐에 다수의 요청, 응답을 넣어 주고 받는 기법인데 이것을 통해 성능 향상을 꾀 했으나 큰 문제가 있다.
    • 순서대로 첫 번째 리소스를 요청하고 응답받고 다음 리소스를 요청하게 되는데 만약 첫번째 리소스를 요청하고 응답이
      지연되면 두 번째, 세 번째 리소스는 첫번째 리소스의 응답처리가 완료되기 전까지 대기하게 되며 이와 같은 현상을
      HTTP의 Head of Line Blocking 이라 부르며 파이프 라이닝의 큰 문제점 중 하나이다.
  • RTT 증가(Round Trip Time) 증가
    • 매 요청별 커넥션을 만들게 되고 TCP에서 동작하는 HTTP 특성상 TCP 3-way Handshake 가 반복적으로 일어나며
      불필요한 RTT증가와 네트워크 지연을 초래하여 성능을 저하 시킨다.
  • 무거운 헤더
    • HTTP/1.1의 헤더에는 많은 메타정보가 담겨있다. 사용자가 방문한 웹 페이지는 다수의 HTTP 요청이 발생하는데
      이 경우 매 요청 마다 중복된 헤더값을 전송하게 된다. 또한 해당 Domain에 설정된 Cookie정보도 매 요청 마다 헤더에
      포함되며 가끔은 요청을 통해 전송하려는 바이트보다 헤더 바이트가 더 큰 경우도 많다.

  HTTP / 1.1 한계 극복

  • Image Spriting
    • 웹 페이지를 구성하는 다양한 아이콘 이미지 파일의 요청 횟수를 줄이기 위해 아이콘을 하나의 큰 이미지로 만들고 CSS에서
      해당 이미지의 좌표 값을 지정해 표시한다.
  • Domain Sharding
    • 커넥션을 생성하고 병렬로 요청을 보내기도 한다. 하지만 브라우저 별로 Domian당 커넥션 개수의 제한이 존재하며, 근본
      해결책은 아니다.
  • Minify CSS/Javascript
    • HTTP를 통해서 전송되는 데이터의 용량을 줄이기 위해 CSS, JS 코드를 축소하여 적용한다.
  • Data URI Scheme
    • HTML 문서내 이미지 리소스를 Base64로 인코딩된 이미지 데이터로 직접 기술하는 방식이며, 요청 수를 줄일 수 있다.
  • Load Faster
    • 스타일시트는 HTML문서 상위에 배치하며, 스크립트는 HTML문서 하단에 배치한다.

• 이러한 노력에도 HTTP/1.1의 단점은 근본적인 해결책이 되지 못했고 구글은 HTTP 고속화를 위해 스피디(SPDY)라는 프로토콜
  을 설계하였다. 후에 이 프로토콜은 HTTP/2.0의 참고 규격이 된다. 스피디는 현재 지원 하지 않는다.

HTTP/2.0

• 완전히 새로운 HTTP 프로토콜 이라기보단 성능향상에 초점을 맞춘 개선된 프로토콜이다.

  HTTP/2.0 동작 방식

  • Multiplexed Streams
    • 한 커넥션으로 동시에 여러개의 메시지를 주고 받을 수 있으며, 응답은 순서에 상관없이 스트림으로 주고 받는다.
      HTTP/1.1의 커넥션 Keep-Alive, Pipelining의 개선판이다.
      
  • Stream Prioritization(스트림 우선 순위 지정)
    • 리소스간 의존관계(우선순위 지정 트리)를 구성하여 통신하므로 브라우저의 렌더링이 늦어지는 문제를 해결한다.
      
  • Server Push(서버 푸시)
    • 서버는 클라이언트의 요청에 대해 요청하지 않은 리소스도 응답 할 수 있다.
      
  • Header Compression(헤더 압축)
    • HTTP/2는 Header 정보를 압축하기 위해 Header Table과 Huffman Encoding 기법을 사용하여 처리하는데
      이를 HPACK 압축방식이라 부르며 별도의 명세서(RFC 7531)로 관리하고 있다.
      
    • 위 그림처럼 클라이언트가 두번의 요청을 보낸다고 가정하면 HTTP/1.x의 경우 두개의 요청 Header에 중복값이 존재해도
      그냥 중복 전송을 하지만 HTTP/2.0은 헤더에 중복값이 존재하는 경우 Static / Dynamic Header Table 개념을
      사용하여 중복 헤드를 검출하고 중복된 헤더는 인덱스 값만 전송하고 중복되지 않은 헤더정보의 값은 Huffman Encoding
      기법으로 인코딩 처리 하여 전송한다.
      
  • Streams, messages, and frames (스트림, 메시지 및 프레임)
    • 스트림: 구성된 연결 내에서 전달되는 바이트의 양방향 흐름이며, 하나 이상의 메시지가 전달될 수 있습니다.
    • 메시지: 논리적 요청 또는 응답 메시지에 매핑되는 프레임의 전체 시퀀스입니다.
    • 프레임: HTTP/2에서 통신의 최소 단위이며 각 최소 단위에는 하나의 프레임 헤더가 포함됩니다.
      이 프레임 헤더는 최소한으로 프레임이 속하는 스트림을 식별합니다.
    • 모든 통신은 단일 TCP 연결을 통해 수행되며 전달될 수 있는 양방향 스트림의 수는 제한이 없아.
    • 각 스트림에는 양방향 메시지 전달에 사용되는 고유 식별자와 우선순위 정보(선택 사항)가 있다.
    • 각 메시지는 하나의 논리적 HTTP 메시지(예: 요청 또는 응답)이며 하나 이상의 프레임으로 구성된다.
    • 프레임은 통신의 최소 단위이며 특정 유형의 데이터(예: HTTP 헤더, 메시지 페이로드 등)를 전달한다. 다른 스트림들의
      프레임을 인터리빙한 다음, 각 프레임의 헤더에 삽입된 스트림 식별자를 통해 이 프레임을 다시 조립할 수 있다.
      

참조:
blog.naver.com, webstylez.egloos.com, blazebyte.blogspot.kr, mindnet.tistory.com/entry
aroundck.tistory.com/5149, developers.google.com/web/fundamentals/performance/http2