4장 커넥션 관리

이 장에서 배울 것은

1. HTTP는 어떻게 TCP 커넥션을 사용하는가 
2. TCP 커넥션의 지연, 병목, 막힘
3. 병렬 커넥션, Keep-alive 커넥션, 커넥션 파이프라인을 활용한 HTTP 최적화 
4. 커넥션 관리를 위해 따라야 할 규칙들

---

TCP 커넥션 

TCP는 세그먼트라는 단위로 데이터 스트림을 잘게 나누고, 세그먼트를 IP 패킷으로 불리는 봉투에 담아서 인터넷을 통해 데이터를 전달함

---

TCP 성능의 중요 요소

1. TCP 커넥션의 핸드셰이크 지연

작은 크기의 데이터 전송에 커넥션이 사용된다면 이런 패킷 교환은 HTTP 성능을 크게 저하시킬 수 있다.

• 왜냐하면 크기가 작은 HTTP 트랜잭션은 50% 이상의 시간을 TCP를 구성하는데 쓰기 때문이다.

 

TCP를 맺는 순서는 아래와 같다.

1. 클라이언트는 새로운 TCP커넥션을 생성하기 위해 작은 TCP패킷(40~60바이트)인 SYN 플래그를 가진 패킷을 보낸다.
2. 서버는 해당 패킷을 받고, 몇 가지 커넥션 매개변수를 산출하고, 커넥션 요청이 받아들여졌음을 의미하는 SYN, ACK 플래그를 포함한 TCP 패킷을 보낸다.
3. 마지막으로 클라이언트는 커넥션이 잘 맺어졌음을 의미하는 ACK 패킷과 함께 데이터를 보낸다.

TCP 3-way Handshake

TCP를 끊는 순서는 아래와 같다.

1. 클라이언트가 연결을 종료하겠다는 FIN 플래그를 가진 패킷을 보낸다.
2. 서버는 ACK 확인 메시지를 보내고, 자신의 통신이 끝날 때까지 기다리는데, 이 상태가 TIME_WAIT
3. 서버가 통신이 끝났으면 연결이 종료되었다고 클라이언트에게 FIN 플래그를 가진 패킷을 보낸다.
4. 클라이언트는 ACK 확인 메시지를 보낸다.

TCP 끊을 떄 4-way Handshake

 

만약 서버에서 FIN 패킷을 전송하기 전에 전송한 패킷(ACK)이 Routing 지연이나, 패킷 유실로 인한 재전송 등으로 인해 FIN 패킷보다 늦게 도착한다면?
- 클라이언트는 뒤늦게 도착한 패킷이 있다면, 이 패킷은 Drop 되고, 데이터는 유실됨
- 이를 대비하여, 클라이언트는 FIN을 수신하더라도 일정시간 동안 세션을 남겨놓고, 잉여 패킷을 기다리는데, 이 과정을 TIME_WAIT이라 함

 

2. 확인 응답 지연 

• 각 TCP 세그먼트는 순번과 데이터 무결성 체크섬을 가진다. 이 세그먼트의 수신자는 세그먼트를 온전히 받으면 작은 확인 응답 패킷을 송신자에게 반환한다.
• 확인 응답은 크기가 작기 때문에, TCP는 같은 방향으로 송출되는 데이터 패킷에 확인응답 패킷을 편승한다.
  • TCP 스택은 확인응답 지연 알고리즘을 구현한다.
  • 이는 송출할 확인응답을 특정 시간 동안 (보통 0.1~0.2초) 버퍼에 저장해 두고, 편승할 송출 패킷을 찾는다.
  • 찾지 못하면 별도 패킷을 만들어 보낸다.
• 이러한 확인 응답지연 알고리즘으로 인한 지연이 자주 발생한다. 왜냐하면 확인 응답이 편승할 패킷이 많지 않기 때문이다.

3. TCP 느린 시작

• TCP 커넥션은 시간이 지나면서 자체적으로 튜닝되어, 처음에는 커넥션의 최대 속도를 제한하고 데이터가 성공적으로 전송됨에 따라 속도 제한을 높여나간다. 이를 TCP 느린 시작이라 한다.
  • 급작스러운 과부하를 방지하기 위해서 사용한다.
• 이런 혼잡제어 기능 때문에, 새로운 커넥션은 이미 어느 정도 데이터를 주고받은 튜닝된 커넥션보다 느리다.
  → HTTP 에는 이미 존재하는 커넥션을 재사용하는 기능이 있다. (connection: keep-alive)

4. 네이글 알고리즘과 TCP_NODELAY

• 네이글 알고리즘은 네트워크 효율을 위해 패킷을 전송하기 전에 많은 양의 TCP 데이터를 한 개의 덩어리로 합치는 것을 말한다.
• 만약 작은 양의 패킷을 많이 보낸다면 네트워크 성능은 크게 떨어진다. (헤더만 하더라도 40바이트 상당이다.)
• 네이글 알고리즘은 세그먼트가 최대 크기(LAN 상 1500바이트)가 되지 않으면 전송을 하지 않는다.
  • 다만 확인응답을 받았을 경우 최대 크기보다 작은 패킷의 전송을 허락한다.
• 네이글 알고리즘은 HTTP 성능에 여러 문제를 발생시킨다.
  1. 크기가 작은 HTTP 메시지는 패킷을 채우지 못하기 때문에, 앞으로 생길지 모를 추가 데이터를 기다리며 지연
  2. 네이글 알고리즘은 확인 응답 지연과 함께 쓰일 경우 형편없이 동작함
  - 네이글 알고리즘은 확인 응답이 도착할 때까지 데이터 전송을 멈추고 있는 반면, 확인응답 지연 알고리즘은 확인 응답을 100~200밀리 초 지연시킨다.

5. TIME_WAIT의 누적과 포트 고갈

• TCP 커넥션의 종단에서 TCP 커넥션을 끊으면, 종단에서는 커넥션의 IP주소와 포트 번호를 메모리의 작은 제어 영역에 기록해 둔다.
  • 이 정보는 같은 주소와 포트 번호를 사용하는 새로운 TCP 커넥션이 일정 시간 동안 생성되지 않게 하기 위한 것.
  • 이전 커넥션과 관련된 패킷이 그 커넥션과 같은 새로운 커넥션에 삽입되는 문제를 방지
• 주로 성능테스트 시에 문제가 발생한다.
• 성능 테스트를 위한 Client가 1개 이고, 측정 대상 서버가 1개일 경우 TCP Connection에서 변하는 값은 Client의 포트번호이다.
• 이때 Client가 임의 포트 60000개를 사용할 수 있고, TIME_WAIT이 2분이라고 했을 때, 초당 500개 이상의 트랜잭션을 발생시키면 포트가 고갈된다.

---

TCP 성능향상 기술 

1. 병렬 커넥션 

• 병렬 커넥션이란 클라이언트가 여러 개의 커넥션을 맺음으로써 여러 개의 HTTP 트랜잭션을 병렬로 처리할 수 있게 하는 기술이다.
• 이는 순차적인 커넥션보다 더 빠르게 로드할 수 있다.
• 하지만 일반적으로는 빠르지만 항상 빠른 것은 아니다.
  - 클라이언트 ↔ 서버 사이의 네트워크 대역폭이 좁을 때는 효과가 없다.
  - 수많은 커넥션에 따른 부하로 인해 성능 저하가 발생할 수 있다.
  - 보통 1개의 클라이언트당 4개의 커넥션을 맺도록 한다.

 

2. 지속 커넥션 

• 처리가 완료된 후에도 계속 연결된 상태로 있는 TCP 커넥션을 지속커넥션이라 한다.
• 커넥션을 재사용하면, TCP를 맺기 위한 준비작업 (3-way handshaking) 이 필요 없기 때문에 더 빠르게 데이터를 전송할 수 있다.
• TCP 느린 시작에 따른 성능 저하도 고려하지 않을 수 있다.
• keep-Alive 옵션
  • Keep-Alive 헤더는 커넥션을 유지하기를 바라는 요청이다.
  • 요청 헤더에 Connection: keep-alive 가 있어야 응답 헤더에 Keep-Alive가 온다.
  • Keep-Alive 헤더의 옵션
    • timeout 파라미터는 Keep-Alive 응답헤더를 통해 보낸다. 커넥션이 얼마간 유지될 것인지를 의미한다. close 요청은 서버에서 하며, 해당 시간이 지나면 서버의 커넥션은 FIN_WAIT2 상태로 넘어간다.
    • max 파라미터는 Keep-Alive 응답 헤더를 통해 보낸다. 커넥션이 몇 개의 HTTP 트랜잭션을 처리할 때까지 유지될 것인지를 의미
• Keep-Alive과 Proxy
  • Keep-Alive 헤더는 이웃한 홉끼리 전달되어야 하는 헤더다. 즉 다음 홉에는 전달되서는 안된다.
  • 하지만 중간에 멍청한 Proxy가 있을 경우 Keep-Alive를 서버에 전달함으로써 클라이언트와 서버는 커넥션이 유지되어 있는 것으로 알고 있으나, 중간에 Proxy는 그것을 지원하지 않기 때문에 Hang이 발생한다.
  • 이를 해결하기 위해 Proxy-Connection 이란 헤더를 사용하기는 하나, 이 또한 여러 개의 Proxy 중 멍청한 Proxy가 있으면, 무용지물이다.
• HTTP/1.1에서의 지속커넥션은 기본적으로 지속커넥션이 활성화되어 있기 때문에 커넥션을 끊을 경우 Connection:close 헤더를 명시하여야 한다.
  • HTTP/1.1에서의 지속 커넥션 역시 앞서 Keep-Alive와 Proxy에 따른 문제점이 있기 때문에 몇 가지 제한과 규칙이 있다.

3. 파이프라인 커넥션 

• 지속 커넥션과 병렬커넥션 조합으로, 여러 개의 요청이 지속 커넥션을 유지하는 것을 파이프라인이라 한다.
• 파이프라인에는 여러 가지 제약이 있다.
  1. HTTP 클라이언트는 커넥션이 지속 커넥션인지 확인하기 전까지는 파이프라인을 이어선 안 된다.
  2. HTTP 응답은 요청과 같은 순서로 와야 한다.
  3. HTTP 클라이언트는 커넥션이 언제 끊어져도, 다시 요청을 보낼 준비가 되어 있어야 한다.
  4. POST 요청과 같이 비멱등성인 경우 파이프라인을 통해 보내면 안 된다.