컴퓨터 네트워크 기본 6

http://www.kocw.net/home/search/kemView.do?kemId=1169634

컴퓨터네트워크

https://media.pearsoncmg.com/intl/ge/2021/cws/ge_kurose_compnetwork_8/cw/index.php

Companion Website | Computer Networking: A Top-Down Approach, Global Edition, 8/e

---

TCP: 개요

Point-to-Point

  - one sender, one receiver

point-to-point

reliable, in-order byte stream

  - no "message boundaries"

What is a message boundary?

... A "message boundary" is the separation between two messages being sent over a protocol. UDP preserves message boundaries. If you send "FOO" and then "BAR" over UDP, the other end will receive two datagrams, one containing "FOO" and the other containing "BAR".

If you send "FOO" and then "BAR" over TCP, no message boundary is preserved. The other end might get "FOO" and then "BAR". Or it might get "FOOBAR". Or it might get "F" and then "OOB" and then "AR". TCP does not make any attempt to preserve application message boundaries -- it's just a stream of bytes in each direction.

https://stackoverflow.com/questions/9563563/what-is-a-message-boundary

pipelined

  - TCP congestion and flow control set window size

send & receive buffers

send & receive buffers

TCP buffers

P1과 P2가 TCP로 연결되어 있을 때 둘 다 p1이 send 한다면 p2는 receive 해야 하고 p2가 send 하면 p1이 receive 해야 하므로 P1, P2는 sender이면서 receiver이다. 따라서 둘은 send buffer(window)도 갖고 있으면서 receive buffer도 갖고 있어야 한다.

 

full duplex data

  - bi-directional data flow in same connection (동일한 연결에서 양방향 데이터 흐름)

  - MSS: maximum segment size

connection-oriented

  - handshaking

flow controlled

  - receiver의 능력을 고려하려 전송량을 조절

 

TCP segment 구조

TCP segment structure

transport layer는 application layer에서 내려온 message에 header를 붙여 segment를 만들고 network layer는 transport layer에서 내려온 segment에 header를 붙여 packet을 만든다. 데이터를 보낼 때 각 layer의 동작은 단순히 상위 layer에서 내려온 데이터에 header만 붙여 바로 밑 layer로 보낼 뿐이다. 이를 생각해보면 각 layer에서 보장하는 프로토콜들의 동작은 header에 담긴 값을 통해 하는 것이라는 것을 알 수 있다. 다시 말해, 전송할 때는 header를 붙이고 수신할 때는 header에 담긴 값을 해석하여 각 계층의 protocol 동작을 구현하는 것이다.

 

이제 위 TCP segment 구조를 살펴보자.

source port#, dest port#

  - source port#는 sender의 socket Identifier가 들어가고, dest port#는 receiver의 socket identifier가 들어간다. 

sequence number

  - TCP에서 sender가 segment header에 적는 seq#는 data 부분의 제일 첫 바이트의 순서 번호이다.

TCP sequence number

acknowledgement number

  - packet loss 발생 시 ACK 전송을 위해 있다.

receive window

  - receiver가 얼마큼의 segment를 감당할 수 있는지를 계속 알려주는 용도

  - flow control을 위해 사용된다.

checksum

  - packet error 발생을 감지하는 용도

 

** TCP에서 사용하는 ACK는 cumulative ACK이다.

Go-Back-N에서 사용하는 ACK와 비슷한데, 다른 점이 있다.

GBN에서 ACK10은 10번까지 잘 받았고 11번을 보내달라는 의미지만,

TCP에서 ACK10은 9번까지 잘 받았고 10번을 보내달라는 의미다.

TCP Seq#, ACK

위 그림을 순서대로 해석하면

1. Host A가 Host B에게 "내가 지금 보내는 건 seq#42번이고 네가 보낸 78번 segment까지 잘 받았어(79번 줘)" 전송

2. Host B가 Host A에게 "내가 지금 보내는 건 seq#79번이고 네가 보낸 42번 segment까지 잘 받았어(43번 줘)" 전송

 

TCP의 여러 재전송 시나리오

<ACK 유실 시나리오>

ACK 유실 scenario

1. Host A가 Host B에게 seq#92 세그먼트 전송

2. Host B가 Host A에게 ACK100 세그먼트 전송

3. 유실 발생!!

4. Host A가 ACK100을 받지 못해 timout 발생 -> Host B에게 seq#92 세그먼트 재전송

5. Host B는 이미 이전에 seq#92를 받았으므로 해당 패킷 drop 하고 ACK 100 재전송

6. ACK100을 전달받은 Host A의 sendBase가 100으로 바뀜

 

 

<Premature timeout 시나리오>

premature timeout

1. Host A가 Host B에게 seq#92, seq#100 전송

2. Host B가 Host A에게 ACK100, ACK120 전송

3. timeout 시간을 너무 짧게 잡은 A가 seq#92를 Host B에게 재전송

4. 와중 ACK100, ACK120가 Host A에게 도착하여 Host A의 sendBase = 120으로 바뀜

5. Host B에게 seq#92가 도착하였으나 이미 받은 패킷이므로 drop 하고 ACK 120을 재전송

6. ACK 120이 Host A에게 도착

 

 

<Cumulative ACK 시나리오>

Cumulative ACK

위 그림을 보면 Cumulative ACK의 장점을 알 수 있다. 도중 아래 시퀀스의 ACK가 유실되더라도 이후 시퀀스의 ACK만 잘 도착하면 그 이전 것들은 모두 문제없이 도착했다는 것이므로 이전 시퀀스 세그먼트를 재전송하지 않아도 된다.

 

1. Host A가 Host B에게 seq#92, seq#100 전송

2. Host B가 Host A에게 ACK100, ACK120 전송

3. ACK 100은 도중 유실되었으나 ACK120은 정상적으로 Host A에게 도착 -> ACK120은 seq#119까지 잘 받았다는 의미이므로 sendBase를 120으로 변경 

 

TCP 성능 향상을 위한 권고사항

receiver 입장에서 모든 요청에 대한 ACK를 전부 응답하기보다 일정 시간 동안 세그먼트를 쭉 받고 가장 나중 ACK를 단 한번만 보내는 것이 더 효율적이다.

  - 예를 들어, seq# 1, 2, 3, 4, 5, ... 100이 도착했을 때 ACK 2, 3, 4, 5, 6, ... 101을 전부 보내기보다 한참 동안 받고 맨 나중에 ACK101만 보내도 문제가 없고 그것이 더 효율적이다.

 

duplicate ACK가 3개 이상이 되면 timeout이 발생하지 않았더라도 해당 packet을 재전송한다.

  - Timeout이 발생하기 전에 어느 정도 해당 패킷의 유실 여부를 판단하는 방법이다. 이를 통해 recovery 시간(loss 혹은 error 발생 시 해당 패킷을 재전송하는 시간)을 줄일 수 있다.

  - 예를 들어, seq#0~99까지 와르르 전송했는데 ACK1, ACK2, ACK3, ACK3(중복 1), ACK3(중복 2), ACK3(중복 3), ... 이렇게 중복된 ACK가 온다면 해당 seq#2 패킷이 유실되었다고 판단하고 그 패킷의 timeout이 발생되기 전에 미리 그 패킷을 재전송하는 것이다.