HTTP 커넥션

HTTP 통신은 TCP를 이용해 순차적이고 손실, 손상되지 않게 메시지를 전달한다.
TCP는 IP 패킷(or 데이터그램)을 통해 데이터를 전달한다.

왼쪽은 HTTP, 오른쪽은 HTTPS이다. OSI 7계층에서 TCP/IP 프로토콜은 4계층에 해당한다.
담에는 OSI 7계층을 따로 정리해야겠다.. 가끔 헷갈림

HTTP가 메시지를 전송할 때, 현재 연결되어있는 TCP 커넥션을 통해서 메시지의 내용을 순서대로 전송한다. 이때 데이터를 segment 단위로 데이터 스트림으로 나누고, 이 segment를 IP 패킷에 담아 전달한다.

전송 과정

각 segment는 IP 패킷에 담겨 전달되는데,
클라이언트 --> [TCP seg1] --> [TCP seg2] --> [TCP seg3] --> 서버
이런 느낌이라고 이해하면 될 것 같다.

IP 패킷

이때 IP 패킷에는 아래와 같은 정보들이 담겨있다.

- IP 패킷 헤더 (발/수신지 ip 주소, 헤더 체크섬) 
- TCP 세그먼트 헤더 (발/수신지 port 번호, TCP 순서 번호, TCP 체크섭)
- TCP 데이터 

TCP 커넥션의 유지

위에서 말했던 것처럼 IP 패킷에서는 발/수신지 ip 주소가, TCP 세그먼트에 발/수신지 port 번호가 담겨있다. 여기에 있는 ip 주소로 특정 컴퓨터 (서버)에 연결되고, port번호로 원하는 어플리케이션을 찾을 수 있다.

TCP 커넥션은 이처럼 발신 ip, 수신 ip, 발신 port, 수신 port로 식별된다. 이 네가지 값이 중복되는 TCP 커넥션은 없지만, 일부가 같을수는 있다.

TCP 소켓

우리는 이런 TCP 커넥션으로 원격 서버의 데이터를 읽고 쓸 수 있다. 클라이언트가 서버에게 커넥션을 요청하고, TCP 커넥션이 생성되면 HTTP 요청-응답을 주고받을 수 있다.

이떄 HTTP 요청-응답은 위의 그림처럼 아래에 TCP 계층이 있기 때문에 TCP 성능에 영향을 받는다.

HTTP/TCP 지연

너무 큰 데이터나 복잡한 자원을 내려받지 않는 이상, 대부분의 HTTP 지연은 TCP 네트워크 지연 때문에 발생한다.

• 클라이언트가 DNS를 사용해 URI에서 IP로 변환하는데 걸리는 지연
• 클라이언트 - 서버가 TCP 커넥션에 걸리는 지연
• 클라이언트가 서버에게 요청을 보내고, 서버가 요청을 처리하는데 걸리는 지연
• 서버가 응답을 보내는데 걸리는 지연

이처럼 TCP 지연은 하드웨어 성능, 네트워트와 서버의 전송 속도, 요청/응답 메시지의 크기 등에 따라 달라진다.

TCP 관련 지연 요소는 이런 것들이 있다.

• TCP 핸드 셰이크 설정
• TCP 느린 시작 (slow-start)
• 데이터를 한 번에 모아 전송하는 nagle 알고리즘
• piggyback과 ACK를 위한 확인 응답 알고리즘

TCP 핸드 셰이크 지연

작은 크기의 데이터 전송에 커넥션이 사용되면 HTTP 성능을 저하시킬 수 있다.

핸드 셰이크 과정을 간단히 묘사하자면
1. 클라이언트 -> 서버 [SYN]
2. 서버 -> 클라이언트 [SYN+ACK]
3. 클라이언트 -> 서버 [확인 응답]
4. 서버 -> 클라이언드 [데이터 전송]
1-2과정이 커넥션, 3은 잘 연결되었다는 확인 응답이다.

크기가 작은 HTTP 트랜잭션은 50% 이상의 시간을 TCP 구성에 쓴다.

확인 응답 지연

아까 TCP 세그먼트안에 들어가는 데이터에 TCP 순서 번호와 체크섬이 있다고 했다. 이때 각 세그먼트의 수신자는 세그먼트를 받았을 때 확인 응답 패킷을 송신자에게 반환한다.
송신자는 확인 응답 패킷을 대기하다가 특정 시간안에 받지 못한 경우는 전송에 문제가 있는 것으로 판단하고 데이터를 다시 전송한다.

확인 응답은 크기가 작기 때문에 송출되는 데이터 패킷에 확인 응답을 piggyBack한다.
이와 같은 piggyback을 늘리기 위해서, TCP 스택은 확인응답지연 알고리즘을 구현한다.
확인응답지연 알고리즘은, 특정 시간동안 버퍼에 데이터를 저장해놓고, piggyback 하기 위한 데이터 패킷을 탐색한다. 만약 시간 내에 찾지 못하면 별도의 패킷을 만들어 전송한다.

TCP Slow-Start

TCP의 데이터 전송 속도는 TCP 커넥션이 만들어진 지 얼마나 지났는지에 따라 달라질 수 있다.
처음에는 TCP 커넥션의 최대 속도를 제한하고, 데이터가 성공적으로 전송되면 속도 제한을 점차 높여가면서 인터넷의 부하와 혼잡을 방지한다.
이 slow start는 한 번에 전송할 수 있는 패킷의 수를 제한하는데, 이것을 혼잡 윈도우제어라고 한다. 이 기능 때문에 새로 연결된 커넥션은 어느 정도 데이터를 주고 받은 커넥션보다 느리다.

Nagle 알고리즘

데이터 크기가 엄청나게 작더라도 전송할 수 있도록 TCP는 데이터 스트림 인터페이스를 제공한다.
TCP 세그먼트의 플래그와 헤더 등이 약 40바이트정도 되는데 데이터가 1바이트라고 가정하면 너무 비효율적인 전송이고, 네트워크 성능도 저하된다.
그래서 이러한 문제를 해결하는 알고리즘이 바로 Nagle 알고리즘이라고 한다.

Segment의 크기가 최대가 되지 않으면 전송하지 않다가, 전송 후 확인 응답을 기다리던 패킷이 확인 응답을 받았거나 전송할만큼의 패킷이 쌓였을 때 저장된 데이터를 전송한다.
(단, 다른 패킷들이 확인 응답을 받았을 경우 최대 크기보다 작은 패킷의 전송을 허락한다.)

하지만 HTTP 성능과 관련해 문제를 발생시킨다.
1. 크기가 작은 HTTP 메시지는 추가 데이터를 기다리며 지연.
2. Nagle + 확인응답지연 조합으로 쓰일 경우 형편없는 동작..

---

😀 학교에서 배우던 컴퓨터 네트워크 과목이 이런건줄은 꿈에도 몰랐다... 그때는 그냥 무조건 암기만 했었는데 뭔가 어떻게 쓰이는지 아는 기분이다!!

이 글은 HTTP 완벽 가이드를 읽고 정리한 글입니다.
저작권 및 기타 문제가 있으면 댓글로 알려주세요.
감사합니다.