본 글은 HTTP 완벽 가이드를 읽고 정리한 글입니다.

TCP 성능 고려 사항

HTTP 트랜잭션 지연

대부분 HTTP 지연은 TCP 네트워크 지연에서 발생한다.

하드웨어의 성능, 네트워크와 서버의 전송속도, 요청과 응답 메시지의 크기, 클라이언트와 서버간의 거리에 따라 크게 달라질 수 있다.

가장 일반적인 TCP 관련 지연들

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

[그림 출처:https://gmlwjd9405.github.io/2018/09/19/tcp-connection.html]

1. 클라이언트는 새로운 TCP 커넥션 생성을 위해 SYN 플래그를 가진 작은 TCP 패킷(40~60바이트)을 전송한다.(커넥션 생성 요청)

2. 서버가 SYN 패킷을 받고, 몇가지 커넥션 매개변수를 산출하고, 커넥션 요청이 받아들여졌음을 의미하는 SYN+ACK 플래그인 TCP 패킷을 클라이언트에게 전송한다.

3. 마지막으로 클라이언트는 커넥션이 잘 맺어졌음을 알리기 위해 서버에게 다시 확인응답신호(ACK) 패킷과 함께 데이터를 전송한다.

아주 큰 데이터를 주고 받지 않는 이상 1과 2에서 눈에 띄는 지연이 발생한다.

크기가 작은 HTTP 트랜잭션은 50% 이상의 시간을 TCP를 구성하는데 사용한다.

TCP 구성으로 인한 지연을 제거하기 위한 방법은?

TCP 세그먼트 구성 정보

그림출처:http://www.ktword.co.kr/test/view/view.php?m_temp1=1889

1-1. 확인응답 지연

인터넷은 패킷 전송을 완벽히 보장하지는 않는다(인터넷 라우터는 과부화가 걸렸을때 패킷을 마음대로 파기할 수 있기 때문이다.)

TCP는 성공적인 데이터 전송을 보장하기 위해 자체적인 확인 체계를 가진다.

각 TCP 세그먼트는 순번과 데이터 무결성 체크섬 을 가진다.

각 세그먼트의 수신자는 세그먼트를 온전히 받으면 작은 확인응답 패킷을 송신자에게 반환한다.

송신자가 특정 시간안에 확인응답 메시지를 받지 못하면 패킷이 파기되거나 오류가 있는것으로 판단하여 데이터를 다시 전송한다.

확인 응답은 크기가 작기 때문에 TCP는 같은 방향으로 전송되는 데이터 패킷에 확인응답을 편승(포함)시킨다.

송출 데이터 패킷과 확인응답을 하나로 묶음으로써 네트워크를 좀 더 효율적으로 사용한다.

확인응답이 같은 방향으로 나가는 데이터 패킷에 편승되는 경우를 늘리기 위해 많은 TCP 스택은 확인응답 지연 알고리즘을 구현한다.

확인응답 지연은 송출할 확인응답을 특정 시간(01.~0.2초)동안 버퍼에 저장해두고, 확인응답을 편승시키기 위한 송출 데이터 패킷을 찾는다. 일정시간 안에 송출 데이터 패킷을 못찾는 경우 확인응답은 별도 패킷을 만들어 전송한다.

요청, 응답 2가지 방식의 HTTP 동작 방식은 확인 응답이 송출 데이터 패킷에 편승할 기회를 감소시킨다.

편승할 패킷을 찾으려고 하면 해당 방향으로 송출될 패킷이 적기 때문에 확인응답 지연 알고리즘으로 인한 지연이 자주 발생

확인응답 지연 알고리즘 관련 기능을 수정 또는 비활성화하자.

1-2. TCP 느린 시작

TCP 커넥션은 시간이 지나면서 자체적으러 튜닝되어, 처음에는 커넥션의 최대 속도를 제한하고 데이터가 성공적으로 전송됨에 따라 속도제한을 높여나간다. 이를 TCP 느린시작 이라 부른다.

이는 인터넷의 급작스러운 부하와 혼잡을 방지하는데 사용된다.

TCP 느린 시작의 과정은

1.TCP가 한번에 전송할 수있는 패킷의 수를 제한

2.패킷이 성공적으로 전달되는 시점에 송신자는 추가로 2개의 패킷을 더 전송할 수 있는 권한을 얻음

3.HTTP 트랜잭션에서 전송할 데이터의 양이 많으면 모든 패킷을 한 번에 전송할 수 없으니 한개의 패킷만 전송 후 확인응답을 기다린다.

4.확인응답을 받으면 2개의 패킷을 보낼 수 있으며, 그 패킷들 각각의 확인응답을 받으면 4개의 패킷을 보낼 수 있게 된다. 이를 혼잡 윈도를 연다 라고 부른다

이 혼잡제어 기능 때문에 새로운 커넥션은 이미 어느 정도 데이터를 주고 받은 튜닝된 커넥션보다 느리다.

튜닝된 커넥션은 더 빠르기 때문에 HTTP에서는 이미 존재하는 커넥션을 재사용하는 기능이 존재한다. 이를 사용하자

1-3. 네이글(Nagle) 알고리즘과 TCP_NODELAY

어떤 크기의 데이터이든 TCP 스택으로 전송 할 수 있도록 TCP는 데이터 스트림 인터페이스를 제공한다.

하지만 TCP 세크먼트는 40 Byte 상당의 플래그와 헤더를 포함하여 전송하기 때문에 TCP가 작은 크기의 데이터를 포함한 많은 수의 패킷을 전송한다면 네트워크 성능은 크게 떨어진다.(1바이트 크기의 패킷을 대량으로 전송하는 것을 실리 윈도 증후군 전송자 라고 부른다. 인터넷 통신에 방해가 된다.)

네이글 알고리즘은 네트워크 효율을 위해 패킷 전송 전 많은 양의 TCP 데이어를 한 개의 덩어리로 합친다.

네이글 알고리즘은 세그먼트가 최대 크기(LAN에서는 1500 Byty 정도, 인터넷 상에선 수백 바이트 정도)가 되지 않으면 전송을 하지 않는다.

다만 모든 패킷이 확인응답을 받았을 경우, 최대 크기보다 작은 패킷의 전송을 허락

다른 패킷들이 아직 전송중이면 데이터는 버퍼에 저장된다.

전송할 만큼의 충분한 패킷이 쌓였을때 버퍼에 저장되어 있던 데이터가 전송된다.

네이글 알고리즘은 HTTP의 여러 성능 문제를 야기한다.

1. 크기가 작은 HTTP 메시지는 패킷을 채우지 못하므로, 생길수도 있는 추가데이터를 기다리며 지연된다.

2. 확인응답 지연과 함께 쓰이면 형편없이 동작한다.

​ 네이글 알고리즘은 확인응답이 도착할 때까지 데이터 전송을 멈추고 있는 반면,

​ 확인응답 지연 알고리즘은 확인응답을 100~200ms 지연시킨다.

3. HTTP 성능 향상을 위해 HTTP 스택에 TCP_NODELAY 파라미터 값을 설정하여 네이글 알고리즘을 비활성화 하기도 한다.(해당 설정은 작은 패킷이 생기지 않도록 큰 크기의 데이터 덩어리를 만들어야 한다.)

1-4. TIME_WAIT의 누적과 포트의 고갈

TCP 통신 성능 측정상황에서는 무조건 한번쯤 봉착할만한 문제이다.

TCP 커넥션의 종단에서 TCP 커넥션을 끊으면, 종단에서는 커넥션의 IP주소와 포트 번호를 메모리의 작은 제어영역에 기록해 놓는다. 이 정보는 같은 주소와 포트 번호를 사용하는 새로운 TCP 커넥션이 일정 시간 동안 생성되지 않게 하기 위한 것으로 보통 2분 정도의 시간 동안 유지된다.(현재는 더 짧게 유지할 수도 있다.)

이전 커넥션의 패킷이 순간 다음 커넥션과 같은 연결값으로 생성된 커넥션에 삽입되면 패킷은 중복되고 TCP 데이터는 충돌된다.

이 때문에 2분정도의 유지 시간은 중복 패킷이 생성되는 경우를 없애준다.

1. 한개의 클라이언트와 웹 서버가 있다.

2. 클라이언트가 서버에 접속할 때마다, 유일한 커넥션을 생성하기 위해 새로운 발신지 포트를 사용한다.

3. 사용할 수 있는 발신지 포트의 수는 제한되어 있고(6만개로 가정) 2분동안 커넥션이 재사용될 수 없으므로 초당 500개(6만/120초)로 제한된다.

4. 서버가 500/s의 트랜잭션을 처리하면 TIME_WAIT 포트 고갈은 일어나지 않게된다.

5. 그러나 포트의 고갈이 일어난다면, 문제 해결을 위해 부하를 생성하는 장비를 더 많이 사용하거나 클라이언트와 서버가 더 많은 커넥션을 맺을 수 있도록 여러 개의 가상 IP 주소를 사용할 수도 있다.