이 신드롬은 통신에서 불필요한 헤더생성을 말한다.
예를 들어, 1byte씩 천천히 Transport Layer에 가져다 두는 Application이 있다고 가정하면
TCP는 1byte를 보내기 위해 최소 20byte 크기의 헤더를 계속해서 생성하여 전송한다.
이런 낭비는 성능의 저하를 유발할 수 있다.
먼저 송신 측에서 발생하는 경우를 보자.

NAGLE이라는 데이터를 입력이 들어올 때마다 보내서 5번의 전송이 일어났다.
이것을 해결하는 알고리즘이 Nagle 알고리즘이다.

이 알고리즘은 매우 단순하다.
만약 여기서 응답이 오기전에 Maximum segemnt size가 넘어가면 그땐 기다리지 않고 보낸다.
이것은 수신 측에서 발생하는 경우의 해결방법이다.
예를 들어 수신측에서 rwnd 값을 계속 1로 전송하면
당연히 송신 측은 작은 값을 계속 보낼 수 밖에 없다.
수신 측에 Application 처리 속도가 너무 느린경우 발생할 수 있는 문제이다.
이것을 해결하는 것은 Clark 처리 방식이다.
간단하게 수신 측의 빈 공간이 Maximum segment size가 되거나 버퍼의 절반 크기만큼 생겼을 때 rwnd 값을 정상적으로 보내고 그게 아니라면 0으로 전송하여 송신 측이 전달하지 않도록 하는 것이다.
혹은 ACK 자체를 안보내서 해결한다.
이 두가지 방식은 모두 sender가 작은 byte을 보내지 않도록 하는 역할이다.

기존에 우리가 살펴본 서버는 listen 함수가 연결요청 대기 큐의 사이즈를 정하여 연결 대기중인 클라이언트들을 큐에 쌓아 두었다.
이 포인트에서 만약 악의적으로 자신의 ip를 바꾸어 연결 요청을 계속 보내면 당연히 연결 불가한 클라이언트 들이 큐에 쌓이게 되고 이것은 서버를 마비시킨다.
이것이 Denial of Service attack이며 Dos 공격이라 부른다.
이러한 공격을 분산하여 보내는 것이 우리가 익히 알고 있는 DDoS 공격이다.
TCP는 신뢰성 보장을 위해 ACK방식을 사용하고
ACK에 대한 ACK은 없다.
그래서 우리는 6가지 ACK 전송 룰에대해 살펴본다.



TCP는 프로세스에게 ordered된 데이터만을 전달한다.

모든 Packet 마다 Timer를 달고 있는데 Timer가 다 지나기전에 Duplicate ACK을 3회 받으면 Loss로 판단하고 바로 재전송한다.

TCP는 cumulative 방식을 사용하기 때문에 ACK이 하나 Loss되어도 별 문제 없는 경우가 있다.
위 그림에서 ACK 901은 900번까지의 수신을 확인해주기에 701에 대한 Loss를 처리해준다.
하지만 ACK Loss로 인한 Deadlock 상황도 존재한다.

만약 ACK에서 rwnd 값을 0으로 전송하면 sender는 대기한다.
이후 버퍼에 빈공간이 생겨 rwnd값을 재전송 하는 과정에서 손실되면 양쪽은 무한대기하게 된다.
이것을 해결하기 위해 Persistence Timer라는 개념이 있다.
이것은 rwnd 0 을 수신 받으면 이 타이머 주기마다 probe data라는 작은 세그먼트를 서버에 계속 보내서
서버가 받을 수 있는 상태인지 아닌지를 체크한다.