Contact 1997

• 이전시간 정리 
• 애플리케이션 레이어 : 메세지 (Message)
• 트랜스포트 레이어 : 세그먼트 (Segment)
• 네트워크 레이어 : 패킷 (Packet)

애플리케이션에 있는 프로세스 계층들이 reliable 하게 통신할 수 있도록 하는 통신은 ? TCP

TCP 라는 것은 특정 센더 혹은 리시버가 있는 것이 아니라 각각의 엔드포인트들은 센더면서 리시버이다. 왜냐하면 HTTP request 와 response 가 같이 작용되기 때문이다. 따라서 버퍼는 각 TCP 마다 두 개씩 존재한다. (Send Buffer / Receive Buffer)

• Send Buffer
• 애플리케이션에 내려온 메세지가 담긴다.
• 세그먼트를 통해서 보낸 데이터가 유실되었을 경우에 재전송을 하기위해서 보관한다.
• 이후에 데이터가 정상적으로 전송되면 해당 데이터를 삭제한다.
• 하지만 TCP 자체는 하나씩 데이터를 보내기엔 비효율적이기 때문에 파이프라이닝 통신을 한다.
• 그렇게 한 번에 보낼 수 있는 개념 자체를 window size 라고 한다. 그리고 해당 사이즈 만큼의 데이터는 피드백 없이 한번에 전송한다.
• Receive Buffer 
• TCP 는 Reliable 통신도 가능하지만, In-order delivery 도 가능케 한다.
• 따라서 SendBuffer 에서 받은 데이터의 순서를 맞추기 위한 용도로 버퍼가 필요하다.
• 그리고 해당 순서를 맞추기 위해서 sequence number 를 사용한다. (Send Buffer 에 해당 바이트 데이터에 대한 시퀀스 번호가 부여되어 있다.)
• 그리고 Receive Buffer 에서의 시퀀스 번호는 상대방의 시퀀스 번호이다. 어디까지 수신되었는지를 확인하기 위함
• 패킷의 유실 유무는 타이머를 통해서 알 수 있다. 그리고 타이머의 만료시간이 끝날 때까지 피드백이 오지 않으면 유실이라고 판단한다.
• 여기서 타이머의 만료시간을 기다릴때까지 효율성이 떨어지기 때문에 같은 ACKs 의 시퀀스 번호를 중복해서 세 번 받으면 다시 재전송을 한다. 시퀀스 번호를 중복해서 세 번 받는 것은 3-duplicate ACKs 라 하며 재전송 하는 것을 Fast Re-Transmit 이라고 한다.

• TCP 가 제공하는 세가지 중요한 기능
• Reliable data transfer
• Flow control
• Congestion control

• Flow control
• 얼마나 빠른 속도로 보낼 것인지에 대한 결정 요소 두가지 존재
• 리시버가 얼마나 받아들일 준비가 되어있는지 => 리시버의 능력 => Flow control
• 중간 네트워크 상태의 혼잡유무 => Congestion control
• 리시버가 자신의 상태를 계속 피드백을 주면 해결이 가능한가?
• TCP 헤더에 리시브 윈도우가 있기 때문에 해당 사이즈만큼만 데이터를 보내주면 해결 가능
• Corner case ) 리시브 버퍼가 가득 찬 경우
• TCP 헤더 필드에 0을 써서 센더 측에 보낸다. 
• 리시브 버퍼에 공간이 생기기 전까지 보내지 않는다.
• ...
• 이후 리시브 측의 센더 버퍼에 보낼 ACKs 가 없어서 교착 상태에 빠지는 경우가 있다. 
• 하지만 센더 측에서는 주기적으로 1Byte 크기의 세그먼트를 날리는 행위를 통해서 이를 해결한다.

• Silly Window Syndorme
• 설명
• 유저 애플리케이션이 데이터를 많이 생성해서 데이터를 많이 내려보내면 상관없음
• 센더 버퍼는 항상 가득하기 때문에 세그먼트를 만들어 보내는 경우, 
• 세그먼트(데이터 영역 + 헤더 영역) 를 가득 채워서 보내면 좋다. (오버헤드를 줄일 수 있기 때문에)
• 유저 프로세스가 데이터를 늦게 생성한다면 ?
• 세그먼트를 얼마나 자주 만들어서 데이터를 보내야하는가에 대한 문제제기를 할 수 있다.
• 따라서 데이터를 채우는 어느정도의 기준을 만들어주어야 한다.
• 데이터 생성하는 즉시 바로바로 데이터를 보낸다면 오버헤드, 낭비가 된다.
• 데이터 기다리기에도 불완전한 상황이다.
• Nagle's Algorithm 이 등장
• 처음 TCP 는 데이터가 있으면 1 Byte 라도 보낸다.
• 그 이후부터는 세그먼트를 만들고 데이터를 채우면서 보낼 준비를 한다.
• Maximum Size 가 차는 경우 또는 방금 보낸 세그먼트의 ACKs를 받은 경우 보낸다.
• 세그먼트가 다 채워지기 이전에 ACKs 가 왔다는 것의 의미 : 네트워크 상태, 즉 속도가 좋다.
• 세그먼트가 다 채워질때까지 ACKs 가 오지 않았다는 것 의미 : 해당 세그먼트를 가득 채웠기 때문에 바로 송신
• 세그먼트 사이즈를 어떻게 해서 보낼 것인가에 대한 이슈 
• Maximum Size 로 보낼 것인가
• 덜 채워서 보낼 것인가

• Connection Management
• TCP Connection 을 맺어두고 Sequence Number 트랙킹하며 Reliable 과 Flow Control 이전의 이야기
• 센더 측과 리시버 측에서는 최초에 어떻게 서로간의 Sequence Number 를 아는 것인가?
• 어떤 과정을 거치는가? => 의사결정 => 서로 간의 협의
• 2-way handshake
• A와 B 서로간의 요청과 응답에 대해서 한 쪽만 요청에 대한 응답을 얻었을 뿐, 상대방은 얻지 못했다.
• 3-way handshake (Transport Layer 에서 이루어짐)
  

  

• A와 B 서로간의 요청과 응답에 대한 상호간의 연결을 하기 위함
• 1) Client -> Server : SYNbit = 1, Seq = x
  사용할 시퀀스 번호를 선정하고 해당 시퀀스 번호를 TCP 헤더에 담아서 전송 (SYN 1비트 데이터), 데이터가 붙지 않은 TCP 헤더 자체의 패킷을 보내는 것이다. 40Byte SYN 패킷을 전송하는 것이다. (세그먼트가 IP 패킷에 담긴다) 모든 IP 패킷에는 오버헤드가 40Byte 가 붙는다. (패킷 헤더 : 20Byte + 세그먼트 헤더 : 20Byte)
• 2) Server -> Client : SYNbit = 1, Seq = y, ACKbit = 1, ACKnum = x+1
  SYNACK 를 보낸다.
• 3) Client -> Server : ACKbit = 1, ACKnum = y + 1
  SYN에 대한 ACK 이기도 하면서 데이터를 넣어서 보내도 되는 세그먼트이다.

• TCP : Closing a Connection
  

  

• 통신을 끝나고 이후에 네트워크를 끊기 위함 
• Client -> Server : FINbit = 1, Seq = x
  커넥션을 끝내기 위한 FIN 세그먼트를 전송한다.
• Server -> Client : ACKbit = 1, ACKnum = x + 1
• Server -> Client : FINbit = 1, Seq = y
• Client -> Server : ACKbit = 1, ACKnum = y + 1

• Congestion control
• window size 라는 것은 한꺼번에 데이터를 전송할 수 있는 양이다.
• Flow control 은 리시버가 가진 저장공간에 맞게 전송하는 것이다.
• window size 는 상대방의 buffer size 에 따라 유동적으로 변경된다.
• 하지만 window size 는 두가지 요인을 동시에 고려해야 한다.
• Network 의 상황
• Receiver Buffer 의 상황
• window size 를 조절하는 것이 속도를 조절하는 것, 따라서 Network 상황과 Receiver Buffer 에 대한 두 개의 값 중에서 최솟값을 가지고 window size 를 결정한다. 하지만 하드웨어 스펙이 높아지면서 window size 는 대부분 Network 상황을 반영받는다.

정리 )

• 애플리케이션 레이어, 데이터의 단위
• 트랜스포트 레이어, 데이터 단위
• 네트워크 레이어, 데이터 단위
• 애플리케이션에 있는 프로세스 계층들이 reliable 하게 통신할 수 있도록 해주는 프로토콜은
• TCP는 각각이 센더이면서 리시버 (상호 간의 엔드포인트)
• TCP SendBuffer 와 Receive Buffer 설명
• TCP 에서 제공하는 세가지 중요 기능
• Nagle's Algorithm 이란
• 센더 측에서 전송해야할 데이터가 있음에도 불구하고, 상대방의 윈도우 사이즈가 매우 작은 경우가 있다. 이러한 경우 보낼 수 있는 패킷의 크기 자체가 작기 때문에 작은 크기의 패킷을 만들지 않고서는 보내지 못한다. 보낼 수 있는 데이터를 패킷으로 만들지 않고, 가능한 모아서 더 큰 패킷으로 만들어 한번에 보내면 이러한 문제는 발생하지 않을 것. 그 문제에 따라서 고안된 알고리즘이다. 
• Connection Management : 3-way handshaking 설명
• TCP Closing a Connection 설명