전 세계 모든 HTTP 통신은, 지구상의 컴퓨터와 네트워크 장비에서 널리 쓰이고 있는 패킷 교환 네트워크 프로토콜의 계층화된 집합인 TCP/IP를 통해 이루어집니다.
TCP 커넥션
HTTP 커넥션은 몇몇 사용 규칙들을 제외하고는 TCP 커넥션에 불과합니다. TCP 커넥션은 인터넷을 안정적으로 연결해줍니다.
HTTP는 'IP, TCP, HTTP'로 구성된 '프로토콜 스택'에서 최상위 계층으로 TCP는 IP 패킷이라고 불리는 작은 IP 조각으로 HTTP 데이터를 잘라서 전송합니다.
HTTPS는 HTTP에 보안 기능을 더한 TLS 혹은 SSL이라 불리기도 하며 HTTP와 TCP 사이에 있는 암호화(cryptographic encrption) 계층입니다.
컴퓨터는 항상 TCP 커넥션을 여러 개 가지고 있는데 이것을 포트 번호를 통해서 유지합니다.
TCP 커넥션은 네 가지 값으로 식별합니다.
<발신지 IP 주소, 발신지 Port, 수신지 IP 주소, 수신지 Port>
이 네 가지 값으로 중복 커넥션이 없는 유일한 커넥션을 생성합니다.
클라이언트는 TCP 소켓을 이용하여, TCP 종단(endpoint) 데이터 구조를 생성하고, 원격 서버의 TCP 종단에 그 종단 데이터 구조를 연결하여 데이터 스트림을 읽고 쓸 수 있습니다.
TCP API는, 기본적으로 네트워크 프로토콜의 핸드셰이킹, 그리고 TCP 데이터 스트림과 IP 패킷간의 불할 및 재조립에 대한 모든 세부사항을 외부로부터 숨깁니다.
TCP의 성능에 대한 고려
HTTP는 TLCP 바로 위에 있는 계층이기 때문에 HTTP 트랜잭션의 선능은 그 아래 계층인 TCP 성능에 영향을 받는다.
트랜잭션에서 HTTP 트랜잭션에서 발생하는 지연을 알기 위해서 동작 과정을 한번 살펴보겠습니다.
- 클라이언트는 먼저 TCP 커넥션을 맺기 위해서 URI를 알아야 하고 이 과정에서 DNS를 이용합니다.
- TCP 커넥션 요청을 서버에게 보내고 서버가 커넥션 허가 응답을 회신하기를 기다립니다.
- 커넥션이 맺어지면 클라이언트는 HTTP 요청을 새로 생성된 TCP 파이프를 통해 전송합니다.
- 웹 서버는 데이터가 도착하는 대로 TCP 커넥션에서 요청 메시지를 읽고 처리
- 웹 서버가 HTTP 응답을 클라이언트에게 보낸다.
이 과정에서 소모되는 시간적 소모는 클라이언트와 서버가 패킷을 주고 받는 과정이 데이터를 처리하는 시간 보다 보통 길다는 것을 알아야 합니다.
성능 관련 중요 요소로는 다음과 같은 것들이 있습니다.
- TCP 커넥션의 핸드셰이크 설정
- 인터넷의 혼잡을 제어하기 위한 TCP의 느린 시작(slow-start)
- 데이터를 한데 모아 한 번에 전송하기 위한 네이글(nagle) 알고리즘
- TCP의 편승(piggyback) 확인응답(acknowledgment)을 위한 확인응답 지연 알고리즘
- TIME_WAIT 지연과 포트 고갈
TCP 커넥션의 핸드셰이크의 과정과 TCP의 느린 시작의 경우 네트워크의 TCP에서 매우 자세하게 다루었기 때문에 넘어가고 정리하겠습니다.
확인응답 지연
수신자는 각 TCP 세그먼트가 가지고 있는 순번과 데이터 무결성 체크섬을 확인하여 온전히 받았는지를 확인하고, 작은 확인응답 패킷을 송신자에게 반환합니다.
확인응답은 그 크기가 작기 때문에, TCP는 같은 방향으로 송출되는 데이터 패킷에 확인응답을 '편승(piggyback)' 시킵니다. 이를 위해서 '확인응답 지연' 알고리즘을 구현합니다.
확인응답 지연은 송출할 확인응답을 특정 시간 동안(보통 0.1 ~ 0.2초) 버퍼에 저장해 두고, 확인응답을 편승시키기 위한 송출 데이터 패킷을 찾습니다.
만약 찾았다면 편승시켜서 전송하고, 아니면 별도 패킷을 만들어 전송합니다.
이 방식에는 문제점이 존재합니다.
요청과 응답 두가지 형식으로만 이루어지는 HTTP 동작 방식은, 확인 응답이 송출 데이터 패킷에 편승할 기회를 감소시킵니다.
이것은 해당 알고리즘으로 인한 지연을 자주 발생시킵니다.
따라서, 해당 기능을 수정하거나 비활성화 할 수 있습니다.
네이글(Nagle) 알고리즘과 TCP_NODELAY
TCP는 애플리케이션이 어떤 크기의 데이터든지(심지어 1바이트라도) TCP 스택으로 전송할 수 있도록, 데이터 스트림 인터페이스를 제공합니다. 하지만, 각 TCP 세그먼트는 40바이트 상당의 플래그와 헤더를 포함하여 전송하기 때문에 효율이 떨어집니다.
네이글 알고리즘은 네트워크 효율을 위해서, 패킷을 전송하기 전에 많은 양의 TCP 데이터를 한 개의 덩어리로 합칩니다.
버퍼를 이용하며 전송하기에 충분한 양이 쌓였을 경우 전송하고, 아니면 버퍼에 저장해 둡니다.
다만 다른 모든 패킷이 확인응답을 받았을 경우에는 최대 크기가 아니라도 전송하기도 하고, 다른 패킷들이 아직 전송중이면 데이터는 버퍼에 저장됩니다.
네이글 알고리즘은 HTTP 성능 관련해 두 가지 문제점을 유발합니다.
- 앞으로 생길지 않을지 모르는 추가적인 데이터를 기다리며 지연될 것입니다.
- 확인응답 지연과 함께 쓰일 경우 형편없이 동작합니다.
- 네이글 알고리즘은 확인 응답이 도착할 때까지 데이터 전송을 멈추고 있는 반면,
- 확인응답 지연 알고리즘은 확인응답을 100 ~ 200밀리초 지연시킵니다.
TIME_WAIT의 누적과 포트 고갈
이 부분은 좀 헷갈리는 내용이였으니 자세하게 적도록 하겠습니다.
TCP 커넥션의 종단에서 TCP 커넥션을 끊고 나서, 해당 커넥션을 통해서 전달되던 패킷은 더이상 수신자에게 도달하면 안된다.
또한, 모든 TCP 커넥션은 각각 유일한 커넥션이여야 됨을 앞서 배웠습니다.
이것을 기억해두고 봐봅시다.
한 상황을 가정해 봅시다.
TCP 커넥션의 종단에서 TCP 커넥션을 끊고나서 새롭게 맺은 TCP 커넥션에 이전 TCP 커넥션의 지연된 패킷이 도착했다고 생각해 봅시다.
여기서 우리는 해당 패킷이 현재 TCP 커넥션의 패킷이 아니란 것을 4개의 연결 값을 통해서 확인할 수 있습니다.
하지만, 여기서 만약 새로운 TCP 커넥션이 이전 TCP 커넥션과 같은 값을 가지고 있다면?
이전 커넥션의 패킷이 그 커넥션과 같은 견결 값으로 생성된 커넥션에 삽입되면, 패킷은 중복되고 TCP 데이터는 충돌할 것이다.
이러한 상황을 대비하기 위해서, TCP 커넥션의 종단에서 TCP 커넥션을 끊으면, 종단에서는 커넥션의 IP 주소와 포트 번호를 메모리의 작은 제어영역(control block)에 기록해 놓습니다.
이것은 보통 세그먼트의 최대 생명주기의 두 배 정도('2MSL')의 시간동안만 유지됩니다.
HTTP 커넥션 관리
이 부분의 내용은 다룰 내용이 많기 때문에 다음 링크에서 정리하겠습니다.
Reference
