http://www.kocw.net/home/search/kemView.do?kemId=1169634
컴퓨터네트워크
인터넷을 동작시키는 컴퓨터네트워크 프로토폴을 학습한다.
www.kocw.net
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
VideoNotes Video tutorials illustrating key concepts from the text.
media.pearsoncmg.com
TCP: Flow Control
TCP는 flow control(흐름 제어)를 지원해 준다. sender가 너무 많이, 너무 빨리 전송하여 receiver의 buffer를 오버플로하지 않게끔 조절하는 것을 flow control(흐름 제어)라고 한다. 수신자는 송신자에게 자신의 여유 공간(RevWindow)을 적어 보내고 송신자는 해당 값을 읽고 receive buffer의 여유 공간에 맞게 데이터를 전송하는 방식이다.
receive buffer의 데이터는 전송 계층의 위 계층인 application layer가 read를 할 때 application layer로 전달되며 전달된 데이터는 buffer에 계속 저장해 놓을 필요가 없으니 삭제된다. 그러면 빈 공간이 더 생기게 되고 더 많은 세그먼트를 받을 수 있게 된다.
Q. 만약 수신자의 receive buffer가 꽉 찰 때까지 application layer에서 read를 하지 않아 버퍼에 빈자리가 없다면 receive window가 0이 된 것이므로 receiver는 여유 공간을 0이라고 적어 sender에게 보낼 것이다. 그러면 sender는 세그먼트를 더 이상 보내지 않을 텐데, 나중에 read를 하여 수신자의 receive buffer에 자리가 생긴 뒤에도 sender는 그 사실을 모를 것이므로, 둘 다 아무 통신도 않고 쭉 가만히 있을 것이다. 이 문제를 어떻게 해결할 수 있을까?
A. receiver가 receive window에 0을 적어서 보내면 sender는 data 부분이 텅 빈 혹은 1bit가 채워져 있는 공 segment를 receiver에게 보낸다. 이렇게 하면 receiver의 receive buffer에 다시 자리가 생겼을 때를 알 수 있으므로 문제가 해결된다.
TCP: Connection Management
TCP가 올바르게 작동하기 위해 client와 server 간 연결이 수립되어야 한다. 이 연결 과정을 Three way handshake라고 하며 각 단계는 다음과 같다.
Step 1: client는 server에게 TCP SYN 세그먼트를 보낸다.
- client 측 시작 sequence number를 보낸다.
- segment header를 보면 SYN이라는 공간이 있는데 보통은 0이지만 3-way-handshake를 시작할 때 해당 bit를 1로 적어 보낸다.
- data는 담겨있지 않다.
Step 2: server는 SYN을 수신하고 SYNACK 세그먼트로 응답한다.
- server 측 시작 sequence number를 보낸다.
- 마찬가지로 SYN 비트를 1로 적어 보낸다.
- client가 보낸 SYN에 대한 ACK이다.
Step3: client는 SYNACK을 수신하고 데이터를 포함할 수 있는 ACK 세그먼트로 응답한다.
- 이때 SYN 비트에 0을 적어 보내며 이후에도 계속 0이다.
- step1과 step2와 달리 실제 보내고 싶은 데이터를 보낼 수 있다. (step3까지도 실제 데이터를 안 보낼 수도 있다.)
Closing TCP Connection
연결을 했으면 언젠가 끊는 것도 있어야 한다. client가 socket을 닫으면(clientSocket.close();) 다음과 같은 순서로 TCP 연결이 끊긴다.
Step 1: client가 server에게 TCP FIN을 보낸다.
- header에 해당 기능을 위한 1비트 공간이 있다.
- client close
Step 2: server는 client에게 보낼 게 있다면 그거 다 보내고 마지막에 FIN을 보낸다.
- 마지막 FIN을 보내면 -> server close
Step 3: client는 server가 보낸 FIN에 대한 ACK를 보내고 일정 시간 'time wait'을 한 뒤 통신을 끊는다. (closed)
Step 4: server는 자신이 보낸 FIN에 대한 ACK를 받으면 통신을 곧바로 끊는다. (closed)
Q. 왜 client가 server에게 FIN에 대한 ACK를 보내고 일정시간 기다릴까. 바로 끊으면 안 되나?
A. client가 보낸 ACK가 중간에서 소실되면 server는 Timeout이 될 때 해당 FIN을 다시 보낼 텐데 만약 client가 Time wait을 하지 않고 바로 통신을 closed 하고 나가버린다면 server는 영원히 FIN에 대한 ACK를 받지 못할 것이고 이는 server가 영원히 client에게로 FIN을 보낸다는 것이다. 이를 방지하고자 일정 시간 동안 client는 time wait을 갖는다.
TCP: Congestion control
sender와 receiver 사이의 네트워크 혼잡도를 파악하여 알맞은 양과 알맞은 속도로 패킷을 보내는 것을 의미한다.
network가 현재 10만큼의 패킷을 감당할 수 있고(Congestion control)
receiver가 현재 20만큼의 패킷을 감당할 수 있다면, (Flow control)
sender는 packet을 10만큼만 보내야 한다.
network가 현재 10만큼의 패킷을 감당할 수 있고(Congestion control)
receiver가 현재 5만큼의 패킷을 감당할 수 있다면, (Flow control)
sender는 packet을 5만큼만 보내야 한다.
따라서 sender가 보내는 패킷은 Min(network, receiver)가 된다. 여기서 궁금한 점은 receiver의 상태는 receiver가 직접 알려주었는데 network 상태는 누가 어떻게 알려주는 것일까 하는 점이다.
** TCP는 reliable한 protocol이기 때문에 보낸 데이터의 time out이 발생되면 해당 데이터를 다시 보낸다. 이때 TCP의 재전송은 네트워크 상황을 악화시킨다. 예를 들어, 10MB의 데이터만 전송하면 끝인 process가 있다고 가정해 보자. 한 번에 잘 통신이 된다면 네트워크에 딱 10MB만큼의 부담만 주겠지만 한 번 재전송을 한다면 20MB의 부담을 주는 것이고 열 번, 백 번, 천 번 재전송을 하면 더 큰 부담을 줄 것이다. 이는 보통의 경우에는 상관없을지 모르지만 네트워크가 혼잡할 때는 매우 큰 일이다. 게다가 나만 이렇게 재전송을 하는 것이 아니라 다른 사람들도 백 번, 천 번 재전송을 할 것이기 때문에 네트워크는 점점 혼잡해질 것이고 결국 그 누구의 데이터도 원하는 목적지에 도달하지 못할 것이다. (꽉 막혀 움직이지 않는 고속도로를 생각해 보자.) 따라서 네트워크가 혼잡하다면 혼잡한 만큼 재전송을 적게 하는 것이 나를 돕고 남을 돕는 것이다. 이것이 Congestion control이 있는 이유이다.
Congestion control의 두 가지 접근 방법
End-end congestion control
- Network로부터 어떤 피드백도 받지 않는다.
- 각 end-system에서 패킷 loss와 delay를 보고 네트워크 혼잡도를 대충 추측한다.
- 실제 TCP가 사용하는 방식이며, 유추하는 것이므로 아주 정확하진 않다.
Network-assisted congestion control
- router가 각 end-system에게 현재 네트워크 혼잡도를 알려준다.
- 혼잡을 나타내는 단일비트를 사용한다. (SNA, DECbit, TCP/IP ECN, ATM)
- 정확한 혼잡도를 알 수 있다.
- router는 전달받은 packet을 forward하기도 바쁜데 이거 할 시간이 없다.
Congestion control의 세 가지 주요 단계
1. Slow Start
- 네트워크가 어느 정도까지 버틸 수 있을지 모르니까 0부터 시작해 보내는 양을 늘려나가자.
- 1, 2, 3, 4 이렇게 증가시키는 것은 너무 느리니까 1, 2, 4, 8, .. 이런 식으로 빠르게 증가시켜 보자.
2. Additive increase
- 병목 근처에 온 것 같으니까 천천히 증가시키자
3. Multiplicative decrease
- 패킷 drop이 발생되었다 !!
- 보내는 양을 줄이자 !!
- 보내는 양을 -1, -2 이런 식으로 줄이는 것은 네트워크 혼잡도 개선에 별 도움이 안 된다. 한 번에 확 줄이자. (고속도로가 꽉꽉 막혔을 때 자동차 한 대 혹은 두 대를 없앤다고 혼잡도가 개선되진 않는다 절반정도로 훅 줄이는 것이 빠르고 확실한 방법이다.)
** Slow Start에서 send 측 send buffer의 window size가 exponential하게 증가하고, Additive increase에서 linear하게 증가하며 Multiplicative decrease에서 절반으로 감소한다. congestion control은 TCP에서 send buffer의 window size를 조절하여 목적을 달성한다.
** Multiplicative decrease의 감소는 절반일 수도 있고, 아예 1부터 다시 시작할 수도 있다. 이는 구현에 따라 다르며 최근에는 time out으로 인해 packet loss가 발생할 경우 1부터 다시 시작하고, 3 dup ACK일 경우 절반으로 줄이는 방법을 채택했다.
'네트워크' 카테고리의 다른 글
| 컴퓨터 네트워크 기본 9 (2) | 2023.01.15 |
|---|---|
| 컴퓨터 네트워크 기본 8 (0) | 2023.01.11 |
| 컴퓨터 네트워크 기본 6 (0) | 2023.01.09 |
| 컴퓨터 네트워크 기본 5 (0) | 2023.01.09 |
| 컴퓨터 네트워크 기본 4 (0) | 2023.01.09 |