HTTP 완벽가이드 4장 - 1. TCP 커넥션

TCP 커넥션

: 클라이언트와 서버가 TCP 소켓 인터페이스를 사용해 상호작용하는 과정

socket_with_3way

위쪽(S1~C2) 에서 소켓 열고, 가운데에서(C3, S5, C4) TCP 핸드셰이크, 아랫쪽 실제 통신
HTTP 커넥션은 몇몇 사용 규칙을 제외하고는 TCP 커넥션에 불과하다. TCP는 HTTP에게 신뢰성 있는 통신을 제공
네트워크 계층의 IP로 해당 컴퓨터에 연결, 전송 계층의 Port로 해당 애플리케이션에 연결
- TCP는 포트번호를 통해 여러개의 커넥션을 유지한다.(구분한다)
  <발신지 IP, 발신지 Port, 수신지 IP, 수신지 Port> 를 통해 유일한 커넥션을 생성한다. - 둘은 있을 수 없다.
위 그림 기준 HTTP 트랜잭션을 처리하는 시간은 C6~S7 사이의 과정으로 TCP 커넥션 설정, 요청 전송, 응답 전송과 같은 과정에 비해 짧다.
실제로 대부분의 HTTP 지연은 TCP 지연 때문에 발생한다.
- 원인: DNS loop up, TCP 커넥션 생성(핸드셰이킹), HTTP 요청, 처리, 응답

TCP 패킷(SYN)을 보내고, SYN, ACK 패킷을 받고, ACK 패킷 전송
웬만하면 HTTP 요청 메시지 전체를 담을만큼 ACK 패킷은 큰 경우가 많아 같이보내고, 많은 응답 메시지 역시(html 파일 혹은 리다이렉션) 하나의 IP 패킷에 담긴다.
따라서, 일반적인 경우 TCP 핸드셰이크가 (눈에 띌만큼 충분히 큰) 지연을 발생시킨다고 말하는 것

(혼잡 제어)인터넷의 부하와 혼잡을 방지하기 위해 자체적으로 튜닝된다.
- 튜닝된 커넥션: 느린시작이 적용되고 이미 몇번 사용되어 많이 전송하도록 변한 커넥션 - 지속 커넥션과 연관
혼잡 윈도우를 연다 : 처음에는 패킷 하나, ACK를 받으면 2개를 보낼 권한, 또 받으면 4개를 보내는 권한이 생긴다.

애플리케이션이 작은 크기의 데이터를 전송할 수 있도록 TCP는 데이터 스트림 인터페이스 를 제공한다. (버퍼 방식과 다르다).
그러나, 작은 크기의 데이터를 포함하고 있는 많은 수의 패킷을 보내는 것은 성능을 크게 떨어트릴 수 있다.
네이글 알고리즘 : 세그먼트가 최대 크기가 되지 않으면 전송하지 않음.
- 앞으로 생기지 않을 데이터를 기다리게 될 수 있다.
- 확인 응답 지연 알고리즘과 함께 쓰이면 더욱 성능 저하를 초래한다. -> 확인 응답 알고리즘은 패킷을 받기를 기다리고, 네이글 알고리즘은 세그먼트가 다 채워지기 전까지 보내기를 미루기 때문에

심각한 성능 저하를 발생시키지만, 실 상황에선 많이 없다.
TCP 커넥션이 끊기고 나서 인터넷 상에 있는 전달되지 못한 패킷이 해당 port, ip를 사용하는 새로운 커넥션에 잘못 유입될 수 있다.
- 이 것을 방지하고자 2MSL(보통 2분) 동안 같은 ip, port를 사용하는 커넥션을 생성하지 못하게 한다.
성능 테스트에서 문제 : 발신지 IP, 수신지(서버) IP, Port는 고정이므로 발신지 Port만 변수가 되는데, Port(6만개) / 2MSL(120초) = 약 500개로 초당 커넥션이 제한된다.

HTTP 완벽가이드