1. TCP services
- TCP(Transmission Control Protocol)는 Application layer와 network layer 사이에 있으며 application과 network의 작업 사이의 중간 역할을 한다.
→ Transport layer 내에 있는 프로토콜 중 하나
<잘 알려진 Port 번호>
| Port | Protocal | Description |
| 7 | Echo | 수신된 datagram을 보낸 사람에게 다시 반향시다. |
| 9 | Discard | 수신된 모든 datagram을 폐기 |
| 11 | Users | 활성 사용자 |
| 13 | Daytime | 날짜 및 시간을 반환 |
| 17 | Quote | 오늘의 quote를 반환 |
| 19 | Chargen | 문자열을 반환 |
| 20 and 21 | FTP | 파일 전송 프로토콜(데이터 및 제어) |
| 23 | TELENT | 터미널 네트워크 |
| 25 | SMTP | 단순 메일 전송 프로토콜 |
| 53 | DNS | 도메인 이름 서버 |
| 67 | BOOTP | Bootstrap Protocal |
| 79 | Finger | Finger |
| 80 | HTTP | Hypertext Transfer Protocal(Web Server) |
Port number는 16비트(2바이트) 정수형을 사용기 때문에 0 ~ 65535번까지 사용할 수 있다.
<Port number 영역>
0 ~ 1023 : well-known port번호 영역 → UNIX/LINUX에서 루트 권한으로만 열 수 있음
1024 ~ 49151 : 등록된 포트(registered port) → 주로 서버 소켓으로 사용하는 영역
49152 ~ 65535 : 동적 포트(dynamic port) → client가 connect(2) 시 또는 bind(2) 없이 server socket을 생성하여 listen(2)할 경우 자동으로 할당되는 영역
1) Stream delivery
- TCP는 stream delivery를 사용 ( ⇔ UDP : Boundary delivery )
Stream delivery : application에서 만들어진 데이터들의 boundary(경계)를 유지하지 않고 다른 단위로 잘려서 전송
→ TCP의 경우 Byte 단위로 잘라서 전송하기 때문에 Stream of bytes라고 함
Boundary deliver : application에서 만들어진 데이터들의 boundary들이 유지되는 상태로 뭉쳐져 전달되는 형태
2) Sending and receiving buffers
- TCP는 양방향으로 전송할 수 있다. 따라서 각 프로세스는 실제로는 Sending buffer와 receiving buffer를 둘 다 가지고 있음
(1) Sending buffer 영역
1. Sent 영역 : 버퍼가 데이터를 보낼 때 만약 특정 부분이 제대로 전달되지 않았다면 buffer가 프로세스에게 데이터를 다시 요청해야하는데 대신에 buffer 자체가 보낸 데이터에 대한 copy를 하여 저장한 영역
2. Not sent 영역 : 버퍼가 아직 보내지 않은 데이터들이 담겨 있는 영역
3. Empty 영역 : 프로세스에게서 받을 데이터를 담기 위한 비어있는 영역
(2) Receiving buffer 영역
1. Not read 영역 : 프로세스가 아직 읽지 않은 패킷(segment)들을 저장하는 영역
2. Empty 영역 : 패킷을 받았을 때 저장할 수 있는 비어있는 영역
2. TCP Features
1) Numbering System
- 각 연결에서 전송되는 데이터의 바이트 수는 TCP로 번호 매겨진다.
- numbering은 임의의 생성된 번호로 시작
(1) Example
- (문제) TCP 연결이 5,000 바이트의 파일을 전송한다고 가정하자. 첫번째 바이트의 번호는 10,001이다. 데이터가 각각 1,000 바이트씩 5개의 세그먼트(segment)로 전송되는 경우 각 세그먼트의 sequence number는 무엇이냐?
- (해결) 다음은 각 세그먼트의 시퀀스 번호를 보여준다.
Sequence Number : 세그먼트의 sequece number field에 저장된 값으로 해당 세그먼트에 포함된 첫 번째 데이터 바이트에 할당된 번호
Acknowledgment Number : 세그먼트의 acknowledgement number field에 저장된 값으로 상대방으로부터 받아야하는 다음 TCP 세그먼트 데이터 시작 번호
→ Acknowledgment Number를 통해 어디까지 받았는지를 내포함
(2) TCP ACK의 두 가지 방법
Selective ACK : ACK가 가장 최근에 받은 세그먼트의 sequence number을 가짐
(장점) - sender에게 순서에 어긋난 데이터를 알려줌
(단점) - 패킷 크기가 커짐
Cumulative ACK : ACK가 다음에 받아야 할 세그먼트의 sequence number를 가짐
(장점) - sender측 윈도우 조정 용이
(단점) - packet loss 이후의 상황을 자세히 알 수 없다.
3. SEGMENT
- TCP에서 Packet을 segment(세그먼트)라고 한다.
1) TCP segment format
- 세그먼트는 20 ~ 60바이트 크기의 헤더와 Data로 구성
- 세그먼트 헤더는 아래 그림처럼 구성
- Options and padding(노란 부분)을 제외하고 각 행이 4byte씩 20byte가 기본적으로 할당
- Options and padding은 0 ~ 40byte 크기를 가질 수 있고 세그먼트에 따라 다름
1행 : Src/Des port address : 16비트(2바이트)씩 차지
2행 : Sequence number : 32비트(4바이트) 차지
3행 : Acknowledgment nubmer : 32비트(4바이트) 차지 → 보통 ACK이 갈 때는 ack number가 없음
4행 : 1) HELN : 헤더의 길이를 저장
→ 길이/4를 저장(헤더는 20 ~ 60이므로 HLEN은 5 ~ 12의 범위만 있으면 되기 때문에 4비트 할당)
2) Reserved : 6비트 차지 → 예약, 예비
3) Control field : 6개의 flag를 6비트에 저장
4) Window size : 16비트(2바이트) 차지 → TCP의 Window 풀을 나타냄(수신 Window)
5행 : 1) Checksum : 16비트(2바이트) 차지 → TCP에서 필수
→ checksum 이외의 모든 값을 sum 한 후 → 보수 값을 사용
2) Urgent pointer : 16비트(2바이트) 차지
(1) Control field
1. URG : Urgent pointer is valid
2. ACK : Acknowledgment is valid(헤더에 ACK이 포함된 건지를 나타냄 → 유효하면 1로 SET)
3. PSH : Request for push
4. RST : Rest the connection
5. SYN : Synchronize sequece numbers(연결 요청)
6. FIN : Terminate the connection(연결 종료)
(파란색 위주로만 다룰 예정!!!)
(2) Pseudoheader added to the TCP segment
- Pseudoheader는 IP 헤더 안에 존재
(3) Checksum
- Checksum : 중복 검사의 한 형태로, 송신된 자료의 무결성을 보호하는 단순한 방법
→ 나열된 데이터를 더하여 Checksum 숫자를 얻고, 정해진 비트 수의 모듈라로 정해진 비트수로 재구성- 단점 : 완전히 오류 감지는 못함 → 오류가 있어도 Checksum이 정상일 수 있
- CRC(cyclic redundancy check) : TCP/IP, Mac 등의 계층에서 오류검증으로 사용
→ 송신자가 checksum 계산해서 헤더에 넣은 값을 수신자가 다시 checksum을 계산했을 때랑 같으면(0이 되면) 오류가 없는 것- CRC는 Frame header를 제외한 header들에서 에러를 detect(감지)하는 역할
Encapsulation : PC에서 다른 PC로 데이터를 전송할 때 데이터를 패키지화 하는 과정
<에러 감지 순서>
1. IP 헤더에서 checksum을 계산(IP header만 오류 체크)
2. TCP 헤더에서 checksum을 계산(TCP header와 application을 포함한 오류 체크)
TCP에서 checksum의 사용은 mandatory(필수)이다.
4. A TCP connection
- TCP는 connection-oriented(연결지향적)이다. ( ⇔ UDP는 비연결지향적이다)
→ source와 destination 사이에 virtual path를 설정한다.
→ message에 속한 모든 segment가 이 virtual path를 통해 전송된다. - TCP는 higer level(더 높은 수준)에서 작동
- TCP는 IP 서비스를 사용하여 개별 세그먼트를 receiver에 전달하지만 연결 자체를 제어한다.
- 세그먼트는 손실되거나 손상되면 retransmit(재전송)된다.
※ connectionless 프로토콜인 IP의 서비스를 사용하는 TCP가 어떻게 연결 지향적일 수 있을까?
- 요점은 TCP 연결이 물리적인 것이 아니라 virtual(가상)이라는 점!!!
1) three-way handshake를 사용한 Connection establishment
- Three-way handshake : TCP/IP 프로토콜을 이용해서 통신을 하는 응용프로그램이 데이터를 전송하기 전에 먼저 정확한 전송을 보장하기 위해 상대방 컴퓨터와 사전에 세션을 수립하는 과정
→ 신뢰성 보장을 위해 다음의 과정을 거침- Client → SYN → Server : Client가 Server에게 접속 요청하는 SYN 플래그를 보낸다
- Server → SYN + ACK → Client : Server가 Listen 상태에서 SYN이 들어온 것을 확인하고 SYN_RECV상태가 됨
→ SYN+ACK 플래그를 Client에게 전송
→ Server는 ACK을 받기 위해 대기 상태로 변경 - Client → ACK → Server : SYN + ACK 상태를 확인한 Client는 서버에게 ACK을 보내고 연결 성립(Established)
SYN 세그먼트 : 연결 요청 패킷 → 데이터를 전송할 수 없지만, 하나의 sequence number를 사용
ACK 세그먼트 : 응답 패킷 → 데이터를 전송하지 않는 경우, sequence number를 사용
SYN + ACK 세그먼트 : 데이터를 전송할 수 없지만, 하나의 sequence number를 사용
socket : 소켓을 생성하는 함수
bind : 소켓에 IP, Port 번호를 부여하는 함수
listen : 일반 소켓에서 서버 소켓으로 바꿔주는 역할
→ listen을 호출해야 SYN이 왔을 때 SYN과 ACK을 자동으로 전송
connect : connect함수를 실행하면 자동으로 SYN을 보냄
→ block 함수라서 ACK이 올 때까지 대기 후 반환
accept : 연결 요청에 대한 수락을 하는 함수
→ block 함수라서 ACK이 올 때까지 대기 후 반환
2) Data Transfer
- 데이터 전송을 하기 위해 1000 Byte 씩 2번 SYN을 보냄
(8001 → 9000, 9001 → 10000) - Server에서 ACK이 10001이고 데이터를 포함한 패킷을 전송
- 이후 전송할 데이터가 없다면 종
3) Three-way handshake를 이용한 Connection termination
- TCP 연결 종료는 TCP 연결 설정보다 복잡
→ 여러 종료 상황이 존재할 수 있음
→ 한 방향 연결이 종료되어도, 다른 방향은 계속 오픈 상태일 수 있음 - 정상 종료인 경우, TCP 연결 종료는, 양방향 2개 연결을 각 축이 독립적으로 닫게 됨
→ FIN 및 그에 대한 FIN+ACK 의 2쌍을 통해서
→ 따라서 three-way handshake로 진행됨 - Three-way handshake를 이용한 connection termination
- Client → FIN → Server : 클라이언트측 어플리케이션이 종료되면 Server로 FIN 송신 후 FIN_WAIT 상태가 됨
- Server → FIN + AKC → Client : FIN을 수신 후 CLOSE-WAIT 상태가 됨
→ 서버측 어플리케이션이 종료가 시작되면 Client로 FIN + ACK 송신
→ 서버는 LAST-ACK 상태가 됨 - Client → ACK → Server : FIN을 수신한 Client에서 Server로 ACK을 전송
→ Client는 ACK을 보내고 TIME-WAIT 상태로 최대 세그먼트 수명의 2배를 기다린 후 CLOSED 상태가 됨
→ Server는 ACK을 수신하면 CLSOED 상태가 됨
FIN 세그먼트 : 연결 종료 패킷 → 데이터를 전송하지 않는 경우, 하나의 sequence number를 가짐
FIN + ACK 세그먼트 : 데이터를 전송하지 않는 경우, 하나의 sequence number를 가짐
(1) TCP 연결 종료 구분
1. 정상 종료(Normal Close) : 3단계 handshake에 의해 양방향 모두 종료되는 것
2. 반 종료(Half Close) : 양측이 동시에 회선 종료되지 않고, 한쪽 연결이 열린채로 놔두고 종료하는 것
→ 즉, 송신은 가능하지만 수신은 불가능 또는 수신은 가능하지만 송신은 불가능
- 클라이언트가 항상 FIN을 먼저 보냄 → FIN을 보낸 순간 클라이언트에서 서버를 전송될 데이터는 없음!!!
→ 서버에서는 클라이언트로 보낼 데이터는 있을 수도 있음!!!!
- 따라서 클라이언트가 FIN을 보내면 half clase 상태 → 따라서 receive buffer는 여전히 남아 있음
(이유) 서버에서 올 데이터가 있을 수도 있어서!!
3. 동시 종료(Simultaneous Close) : 거의 동시에 양측에서 FIN 세그먼트를 보내는 경우
4. 강제 종료 : TCP Reset 요구(RESET 세그먼트) 기능
4) 전체 TCP 전송 과정
5. State Transition Diagram
1) States for TCP
| State | Description |
| CLOSED | 연결이 없는 상태 |
| LISTEN | Passive open received; SYN 대기중 |
| SYN-SENT | SYN 전송; ACK 대기중 |
| SYN-RCVD | SYN+ACK 전송; ACK 대기중 |
| ESTABLISHED | Connection established(연결 설정); 데이터 전송이 진행 중 |
| FIN-WAIT-1 | 첫번째 FIN 전송; ACK 대기중 |
| FIN-WAIT-2 | 첫번째 FIN에 대한 ACK이 수신; 두번째 FIN 대기 중 |
| CLOSE-WAIT | 첫번째 FIN 수신, ACK 전송; 응용프로그램 종료 대기 |
| TIME-WAIT | 두번째 FIN 수신, ACK 전송; 2MSL time-out 대기 |
| LAST-ACK | 두번째 FIN 전송; ACK 대기중 |
| CLOSING | 양쪽이 동시에 close 상태로 변경 |
FSM(finite-state machine)에서 ESTBLISHED로 표시된 상태는 사실 클라이언트와 서버가 데이터를 전송하기 위해 겪는 두 가지 상태 집합이다.
MSL : Maximum Segment Lifetime(30초 ~ 1분 정도)
2) State transmition diagram
(1) 서버 : LISTEN →(SYN 수신&SYN+ACK 송신)→ SYN-RCVD →(ACK 수신)→ ESTABLISHED →(FIN 수신&ACK 송신)→ CLOSE-WAIT →(FIN 송신)→ LAST-ACK →(ACK 수신)→ CLOSED
(2) 클라이언트 : SYN-SENT →(SYN+ACK 수신&ACK 송신)→ ESTABLISED →(FIN 송신)→ FIN-WAIT-1 →(ACK 수신)→ FIN-WAIT-2 →(FIN 수신&ACK 송신)→ TIME-WAIT →(2MSL만큼 대기)→ CLOSED
3) Time line for a common scenario
RTT(Round Trip Time, 왕복 시간) : 패킷을 목적지로 보낼 때, 패킷이 목적지에 도달하고 나서 해당 패킷에 대해 ACK이 출발지로 다시 돌아오기 까지의 시간 → RTT는 거리마다 다름
<Time wait이 있는 이유>
1. FIN, FIN+ACK, ACK에서 마지막 ACK이 없어졌다고 가정
→ 마지막 FIN이 Loss 됬다고 간주하고 Server에서 다시 FIN 세그먼트를 재전송
→ 만약 time wait이 없고 closed되면 client는 재전송된 FIN을 수신받지 못함
→ 따라서 Server는 ACK을 수령하지 못해 서버 연결 종료를 하지 못함
⇒ Time wait 동안 기다리면서 FIN 재전송이 되는지를 기다림
2. 서버에 연결을 종료하고 약간의 시간 후 재접속을 한다고 가정
→ 똑같은 IP와 Port 번호를 가진 소켓이 다시 만들어져 패킷이 복잡해질 수 있다.
⇒ 기존 connection port를 2MSL동안 살려놓고 다시 SYN이 오면 다른 port번호로 대체한다.
(1) Eco server 코드(반사하는 코드)
- Read : receive buffer에 들어온 데이터를 애플리케이션에 가져 오는 것
→ 데이터가 없으면 block 상태가 되고 데이터가 올 때까지 wait - while문 종료 조건 : read가 0을 반환하는 경우 → 상대가 FIN을 보냈을 때
- clnt_sock : 연결 요청만 받는 소켓
4) Denying a connection
- SYN이 오면 RST를 통해서 패킷 거절
5) Aborting a connection
- RST + ACK을 동시에 전송 → 종료될 때 강제 종료 등의 경우가 생기면 RST + ACK을 전송해 client-server가 모두 즉시 CLOSED 상태가 됨
6) 1 : N = Server : Client의 경우
- 녹색 점(서버 소켓) : SYN/SYN+ACK을 Client와 주고 받는 역할 → SYN을 받으면 소켓을 새로 생성하여 각 Client와 연결
※실질적으로 Client는 녹색 점에 데이터를 보내고 패킷의 헤더를 통해 각 소켓으로 전달하는 형식※ - File descriptor : 0, 1, 2는 고정 → 3에 녹색 점(서버 소켓) / 그 이후에 생성된 소켓들이 할당됨
6. Windows in TCP
- TCP는 각 데이터 전송 방향에 대해 두 개의 windows(send window와 receive window)를 사용한다.
→ bidirectional communcation(양방향 통신)을 위한 four windows - 논의를 단순화하기 위해, 우리는 통신이 단방향일 뿐이라고 가정!!!!
Stop & Wait 방식 : 한번 데이터를 보내면 ACK을 받을 때까지 기다리고, ACK이 도착해야만 다음 데이터를 한번 보내는 방식
Window : sender가 보낼 수 있는 maximum 데이터 크기
→ 상황에 따라 데이터가 소비되는 속도가 다르기 때문에 빈 공간은 때에 따라 다름
→ 따라서 reciever는 sender에게 계속 window size를 알려줘야 함 (헤더에 존재)
1) Send window in TCP
- send window size는 receiver가 보내준 window size(한 번에 보낼 수 있는 패킷의 크기)
→ receiver가 5개 window size를 받으면 방금 보낸 패킷 빼고 남은 거 보냄 - sending buffer의 window : 보낸 데이터에 대한 ACK이 오면 keep해놓고 있던 데이터를 버리고 window를 전체적으로 오른쪽으로 이동
-
- Closing : sender가 ACK 번호를 보고 상대방이 어디까지 받았는지를 확인하고, 상대방이 다 받았다면 더 이상 keep 할 필요가 없으니 반납하고 빈공간을 만든다.
- Opening : 데이터가 receiver에서소비되어 보낼 수 있는 양이 늘어나면 right wall이 오른쪽으로 더 이동
-
2) Receive window in TCP
- receiver window size는 할당된 buffer보다 클 수 없다.
→ buffer에서 읽히기를 기다리는 Byte의 수 = Receiver window size(rwnd) - receiving buffer의 window: 받은 데이터를 소비하고 나면 빈 공간은 버리고 window를 전체적으로 오른쪽으로 이동
- Closing : sending buffer로부터 데이터를 받은 만큼 left wall은 close된다.
- Opening : 데이터가 receiver에서 소비된만큼 right wall이 오른쪽으로 이동하여 window가 열린다.
7. Flow Control
- Flow Control : prodcuer(생산저)가 데이터를 생성하는 속도와 consumer(소비자)가 데이터를 사용할 수 있는 속도의 균형을 맞춘다.
- TCP는 flow control과 error control를 분리힌다.
- error control를 무시한 flow control를 다룰 것이다.
- 송신과 수신 사이의 logical channel이 오류가 없다고 가정!!
1) Sliding Window
- Sliding Window : window의 크기를 가변적으로 조절하여 필요에 따라서 window의 크기를 크게(줄일 수도 있지만 다루지 않음)해서 여러 패킷을 논리적인 하나의 패킷으로 묶어 전송
- rwnd : receiver window size(수신 측 버퍼 여유 용량)
→ receiver application이 가져가는 속도에 맞춰서 변동 - cwnd : congestion window size(송신자가 보낼 수 있는 패킷 크기의 한계)
→ 연결 초기 및 혼잡 상황에서 사용되는 윈도우
→ 연결 초기에 cwnd = 1로 셋팅됨
→ 최대값이 될 때까지 cwnd를 증가 시킴
2) TCP/IP protocol suite
① sender 프로세스 → sender TCP : write 함수를 사용하여 데이터를 buffer에 저장
② sender TCP → receiver TCP : 세그먼트를 sender에서 receiver로 전송
③ receiver TCP → receiver 프로세스 : read 함수를 사용하여 buffer에서 application을 데이터 가져오고 버퍼 비워
④ receiver TCP → sender TCP : Flow control feedback
⑤ sender TCP → sender 프로세스 : Flow contorl feedback
※ Receiver가 소비하는 속도 ⇒ Network 속도
Flow control feedback : 상대 destinatino의 receiving 버퍼가 소비되는 속도를 고려하여 그에 맞춰 TCP가 보내는 패킷의 양을 조절하는 것!!!
Ex) 이미지 파일 같이 큰 파일을 보내려고 할 때
→ 이미지 용량이 buffer보다 크면 write()에서 block된다. 따라서 상대방이 정보를 가져가야 block이 풀리고 TCP가 또 새로운 데이터를 갖다놓음
※ 수신 프로세스가 수신할 준비가 되어 있을 때마다 수신버퍼도 Data를 읽어간다.
→ 수신 TCP가 송신 TCP 제어, 송신 TCP는 송신 프로세스를 제어
3) Example of Flow Control
- client에서 server로의 단방향 통신에서만 고려할 것 → 따라서 window가 하나밖에 없는 것!!
<아래 예시 설명>
1. 클라이언트-서버 연결 요창
1) 클라이언트가 서버에 연결 요청 패킷을 전송
2) 서버가 SYN+ACK 패킷을 보내준다. 해당 패킷에는 rwnd = 800이라는 값이 적혀있음
→ ACK number 값은 101
3) 클라이언트가 해당 SYN 패킷에 대한 ACK 패킷을 보내준다.
2. 데이터 전송
4) 이제 데이터를 101번부터 200byte씩 전송한다.
→ 이때 Sending buffer는 아직 변화 없음
→ Receiving buffer는 200Byte를 받았으니 200만큼 줄어든다.
5) 서버가 이제 600Byte 남았으므로 ACK 패킷에 rwnd값으로 600을 보내준다.
→ 클라이언트가 101~301까지 보낸 데이터에 대한 ACK을 받았으므로 해당 window는 301번까지 window를 close함
6) 이제 클라이언트가 다시 301번부터 300Byte를 보낸다.
→ 이때 서버가 300Byte를 받고, 100Byte를 소비했으므로
→ left wall은 300Byte만큼 close하고 right wall을 100Byte만큼 open함
7) 이제 서버가 다시 300Byte에 대한 ACK 패킷에 rwnd값으로 400을 보내준다.
→ 이제 sending buffer는 300byte를 제거하고 뒤에 100Byte만큼 open함
8) 마지막으로 서버가 스스로 200Byte를 소비하여 receiving buffer의 window가 #601 ~ #1201까지 open됨
→ 이제 rwnd값이 늘어났다고 ACK 패킷을 sending buffer로 rwnd = 600만큼 전송
→ sending buffer는 뒤에 200Byte만큼 open
4) Silly Window Syndrome
- 송신 측 Silly Window Syndrome : Header의 크기(40Byte)에 비해 데이터가 너무 작을 경우 발생하는 비효율성
→ 송신 TCP가 한 번에 1 Byte씩 데이터를 천천히 발생하는 응용 프로그램의 경우
→ 1 Byte 데이터를 포함한 세그먼트가 만들어짐 - 수신 측 Silly Window Syndrome : 수신 TCP에서 소비하는 데이터 양보다 송신 TCP에서 보내는 양이 더 많을 때 발생하는 비효율성
(1) 해결책 : 가능한 큰 byte를 보내자 but, 너무 오래 대기하는 것도 손해
- Nagle 알고리즘(송신 쪽 해결)
① 보낼 데이터가 MSS(Maximum segment size → 보통 536Byte)로 정의된 크기만큼 쌓이면, 무조건 전송
② MSS보다 작을 경우, 이전에 보낸 데이터의 ACK이 오기를 기다림
→ ACK이 도달하면 보낼 데이터가 MSS보다 작더라도 전송
→ ACK이 오기전 MSS만큼 쌓이면 전송
※ default값은 Nagle ON상태이다.
- Clark 해결방법(수신쪽 해결1)
- receiver buffer에 공간이 매우 작을 때, ACK 전송 시 window size = 0으로 전송하여 빈 공간이 MSS 크기가 되거나 buffer의 절반일 때 다시 수신하는 방법
(단점) rwnd = 0으로 보내는 도중에 데이터가 계속 들어올 수 있음 → 최악의 경우 데이터가 버려질 수 있음 - 확인응답의 지원(수신쪽 해결2)
- 일정 크기 이상의 empty space가 생길 때까지 ACK 전송 지연하는 방법
5) SYN Flooding
- SYN Flooding : Client가 보내는 곳의 IP와 Port 번호를 악의적으로 바꾸어서 SYN을 여러개를 보내 연결 요청 대기 큐가 꽉차서 제대로 된 사용자가 SYN을 보낼 수 없게 되는 현상
- 공격자가 서버에 연결 요청
→ 서버는 연결 요청에 응답(SYN + ACK) 전송
→ 공격자가 ACK을 보내지 않음, 서버 연결 요청 대기 큐에 저장
→ 위의 과정을 계속 반복하여 연결 요청 대기 큐가 꽉참
→ 서버 터짐 - DDos : 여러 개의 컴퓨터를 감염시켜 동시에 타깃 컴퓨터에 공격하여 SYN Fooding을 발생시키는 것
- 공격자가 서버에 연결 요청
8. Error Control
- TCP는 신뢰할 수 있는(reliable) transport layer protocol이다. 즉, TCP에 데이터 스트림을 전달하는 애플리케이션 프로그램은 TCP에 의존하여 전체 스트림을 다른 쪽 끝의 애플리케이션 프로그램과 오류 없이, 어떤 부분도 손실되거나 중복되지 않고 순서대로 전달한다!!!
- TCP에서 Error control : checksum, acknowlegment 및 time-out의 세가지 도구를 사용하여 수행됨
ACK 세그먼트는 sequence number를 사용하지 않으며 승인되지 않음 → ACK에 대한 ACK은 없다
데이터가 비정상적으로 도착하여 수신 TCP에 의해 일시적으로 저장될 수 있지만, TCP는 순서에 맞지 않는 데이터는 프로세스에 전달되지 않도록 보장
1) Normal operation
- Rule 1 : 받은 데이터에 ACK을 보낼 때 Sending buffer에 보낼 데이터(수신하고자 하는 다음 순서 번호인 Sequence number)가 있으면 같이 보내는 것
- Rule 2 : 데이터를 받아서 ACK을 보내려고 할 때 Sending buffer에 보낼 데이터가 없으면 최대 50ms만큼 기다리고 보내는 것
- Rule 3 : Rule 2에서 기다리다가 패킷하나가 더 오면 바로 ACK 전송
→ packet 2개를 받으면 즉시 ACK 1개를 보낸다.
2) Lost segment
- Rule 4 : 순서에 어긋나는(out-of-order) 세그먼트가 오면 즉시 ACK을 보냄
→ 수신측은 ACK 세그먼트를 즉시 전송함으로써 sequence number를 알림 - Rule 5 : 누락된 세그먼트가 도착하면 수신하고자 하는 다음 sequece number를 담은 ACK 즉시 전송
수신 TCP는 순서가 지정된 데이터만 프로세스에 전달
→ 순서가 바껴서 들어오는 데이터를 TCP가 알아서 해결 (⇔ UDP는 신경 쓰지 않음)
⇒ 신뢰성 보장이 필요한 경우에는 TCP를 사용!!!(대부분 TCP 사용)
(1) Fast retransmission
- Fast retransmission : 3개의 중복된 ACK이 도착하면 Packet loss로 간주하고 해당 패킷을 재전송함.
- 양방향으로 전송하기 때문에 중복된 ACK이 실제로는 3개 이상이 올 수있다.
- window size가 허락하는 한 Client는 계속해서 데이터를 보낼 수 있다.
(2) Lost Acknowledgment
- ACK이 안 왔지만 window size가 허락되면 계속 SYN을 전송하게 됨
- 따라서 아래의 경우 아무 문제없이 진행됨
- Rule 6 : 중복된 세그먼트를 받으면 수신측은 즉시 폐기하고, 수신하고자 하는 순서에 맞는 즉시 ACK을 전송
- 아래의 경우 보낼 데이터가 없는 상황에서 time-out에서 ACK이 안 왔으므로 데이터를 다시 보냄
Lost acknowldgment는 제대로 처리되지 않으면 deadlock이 발생할 수 있다.
- rwnd = 0을 받게 되면 persistence timer(영속 타이머)가 시작되고 timer가 끝나도 rwnd = k라는 ACK이 오지 않는다면 sender는 probe 패킷(1바이트 크기 데이터)를 보내서 체크한다.
- 아래의 경우는 deadlock이 발생하는 경우를 보여준다. → rwnd = k라는 ACK이 손실된 상황
9. Congestion Control
- TCP의 Congestion Control는 open loop 및 closed loop 메커니즘을 모두 기반으로 함
- TCP는 Congestion을 방지하고 Congestion이 발생한 후 congestion을 감지하고 완화하는 congestion window와 congestion policy을 사용한다.
1) Congestion
- Congestion : 네트워크 상에 패킷들이 너무 많아서 혼잡이 발생하는 경우
- buffer가 꽉 차게 되면 라우터가 패킷을 버림(packet loss) → packet loss의 원인 99%가 라우터가 버려서
rwnd : 수신 측이 보내준 윈도우 크기(Byte 단위)
cwnd : 네트워크 상황을 고려해서 정한 윈도우 크기 → 송신측에서 나온 윈도우 크기(실제로는 Byte단위지만 패킷단위로 아래에서 생각하기) → 무조건 0보다 큰 값을 가짐
<실제 윈도우 크기>
Window size = minimum(rwnd, cwnd)
(1) Packet delay and network load
- Delay : receiver가 받는데 걸리는 시간(파일 하나 받는데 걸리는 시간)
- Capacity : 네트워크의 용량
- Load : 한 네트워크에서 전송되는 패킷의 수
→ Load가 Capacity 근처로 가면 기하 급수적으로 Delay가 증가한다.
→ 이후 어느 시점부터는 데이터가 전송이 안가는 상황이 발생하고 이 상황을 congestion이라고 함
(2) Throughput versus network load
- Throughput(처리량) : 성능(정상적으로 전송되는 데이터의 양)
≠ receiving rate : 순간적인 속
→ 트래픽이 늘어나면 점점 많은 데이터가 전송이 되는데 어느 시점을 넘어가서 congestion이 발생하면 제대로 전송되는 게 없고 처리량이 점점 내려감
→ congestion이 발생하면 packet loss가 생겨서 데이터를 다시 보내야 함 → 시간이 증가
2) Congestion Control
(1) Slow start, exponential increase
- slow start algorithm : 송신 측이 window size를 1부터 packet loss가 일어날 때까지 기하급수적으로 증가
- 초기 window size : 1 MSS
- 매 RTT마다 window size를 2배로 키움(ex. 1, 2, 4, 8, 16 ...)
- 패킷 손실을 감지하면 window size를 1MSS로 줄임
- Threshold( = thresh) : 여기까지만 Slow start를 사용하겠다라는 의미를 가짐
(2) Congestion avoidance, additive increase
- congestion avoidance algorithm : congestion이 감지될 때까지 congestion window의 크기가 추가적으로 증가
- 송신 측이 transmission rate(window size)를 패킷 손실이 일어날 때까지 증가시키는 식의 접근법
- additive increase : 송신 측의 window size를 손실을 감지할때까지 매 RTT마다 1 MSS씩 증가시킨다.
(3) Multiplicative Decrease
- Multiplicative Decrease : 손실을 감지했다면 송신 측의 window size를 절반으로 감소
→ 혼잡이 발생하면 세그먼트 재전송 X, RTO 타이머 만료 또는 3개의 중복 ACK이 수신되는 등의 경우 발생
(4) TCP Congestion policy summary
(5) Congestion example
- 혼잡이 심할 경우 하나 이후에도 packet loss가 더 생길 수 있다.
Window size는 패킷에서 16비트 차지 → 65536(2^16) Byte까지 표현 가능
<아래 그림 설명>
0 ~ 4 RTT : SS방식으로 cwnd가 2배씩 증가
4 RTT : Threshold를 만나게 되어 AI 방식으로 변경
4 ~ 8 RTT : AI방식으로 가다가 Time-out(혼잡)이 발생
8 RTT : time-out이 발생했기 때문에 cwnd는 1부터 시작되고 Threshold는 절반 값이 된다.
8 ~ 12 RTT : SS방식으로 cwnd가 2배씩 증가
12 RTT : SS방식이지만 Threshold를 초과하지 못하고 cwnd는 10이 된다.
12 ~ 14 RTT :AI방식으로 가다가 3 ACKs(packet loss → 혼잡)이 발생
14 RTT : 3 ACKs이 발생했기 때문에 cwnd는 MD가 적용되어 절반 값에서 시작
14 ~ RTT : AI방식으로 cwnd 계속 증가
Threshold는 time-out에 의해서만 바뀐다.
3) Why is TCP fair?
(1) RTT가 같은 두 세션 간의 경쟁
- Additive increase는 throughput 증가와 마찬가지로 기울기가 1이다.
- multiplicative decrease는 throughput을 비례적으로 감소시킴
<그래프를 통해 알 수 있는 점>
RTT가 같은 경우, 각 Connection들의 처리량이 시간이 지날수록 같아짐 → TCP Fair
(2) RTT가 다른 두 세션 간의 경쟁
- RTT가 다르면 TCP not fair → RTT가 작을수록 처리량 증가율이 더 큼
4) Wifi Channels
'컴퓨터 네트워크' 카테고리의 다른 글
| 컴퓨터 네트워크 : Chapter 2. 소켓의 타입과 프로토콜의 설정 (0) | 2023.04.13 |
|---|---|
| 컴퓨터 네트워크 : Chapter 1-1 네트워크 프로그래밍과 소켓의 이해 (0) | 2023.04.13 |
| 컴퓨터 네트워크 : 2. The OSI Model and the TCP/IP proctocal Suite (2) | 2023.04.10 |
