[Computer Network] Chap8. Transport layer (1)

 

 

 

 

 

8. Transport layer 1

- 3계층이 컴퓨터는 찾았고, 4계층은 destination software를 찾는 과정 (process to process)

- 한 프로세스에서 다른 프로세스로 packet을 전달하기 위하여

 

- 가장 유명한 것은 클라이언트 / 서버 구조 / 컴퓨터 2대의 통신 

- 본인이 요청할 때, 내가 local host / 상대편이 remote host

+ 컴퓨터 안의 소프트웨어, process를 지칭하게 됨 -> local process & remote process

 

- Port number – 호스트 운영체제 위에서 돌아가는 다양한 프로세스, 프로그램을 식별하는 번호 (16 bit int)

+ 많이 사용하는 표준 SW 프로그램은 미리 1024개 지정 -> 이외의 값은 임의로 운영체제가 랜덤하게 지정 

- 컴퓨터는 IP address + 내부의 프로세스는 port number

- destination과 source의 IP address & port number 이 4개만 있으면 정확히 찾아갈 수 있다. 

+ Socket Address = IP 주소와 포트 넘버의 combination 

 

- Connectionless Service (UDP) vs Connection-Oriented Service (TCP) -> 연결 설정 및 해제 기반 

- Unreliable Service (UDP, fast 초고속) / Reliable Service (TCP) – 신뢰성이 보장되어야 한다 slow, complex

+ Datalink layer 2계층이 reliable, flow and error control 하는데 4계층에서도 왜? 

-> 3계층 network layer의 인터넷이 unreliable (best effort delivery, 최선을 다하고 버린다.) 신뢰성 보장 X

-> 결국 서비스 바로 밑에 깔린, 4계층 transport layer에서도 reliability 구현해야 한다. + 에러 검출 및 복구

 

* User Datagram Protocol, UDP

- Connectionless, unreliable transport protocol / simple protocol using minimum of overhead

- 신뢰성이 중요하지 않은, 작은 메세지를 상대에게 보낼 때 사용 

+ Well Known ports used with UDP (Echo, Daytime, BOOTPs 등등 미리 정해진 유명한 포트 번호들)

 

- Frame format (header + data) 8 byte 헤더에 각각 16 bit (2 byte)

1. Source Port / 2. Destination Port / 3. Total Length / 4. Checksum (헤더가 박살났는지 여부) 

 

- UDP는 connectionless service, 따라서 각각 독립적인 datagram

-> no error control, no flow control 

 

- Queuing at Client / Server site – 서버가 클라이언트보다 항상 먼저 살아있어야 한다. 

- 클라이언트 프로세스가 살아날 때, OS에게 본인의 랜덤 Source 포트 번호를 받는다.

- UDP 헤더를 더한 이후, IP에게 전달 / 패킷 도착 -> destination port number 보고 적절한 프로세스에게 전달 

 

- UDP 사용 예시 – 파일(FTP)과 같은 대량 데이터 전송에는 적합하지 X

- multicasting 방송을 뿌릴 때 / 라우터 간의 정보를 주고 받을 때 (RIP – routing information protocol) 

- 네트워크 장치들에 대한 소량의 데이터를 가져오는 경우 (없어지면 재요청하면 됨) SNMP 심플 네트워크 관리

 

* Transmission Control Protocol, TCP

- Connection Oriented Protocol, flow and error control, congestion control 

- TCP Well known port number -> FTA (File Transfer Protocol – TCP가 더 적합), HTTP

* Stream Delivery Service / stream-oriented Protocol TCP / TCP는 패킷을 보내는 것이 X (UDP와 다름)

-> 바이트를 보내는 virtual connection을 뚫는 것 

- Circular queue 유한 버퍼를 만든다, 버퍼의 단위는 바이트

1. 보냈는데 아직 응답을 받지 못함 / 2. 보낼 애들 / 3. 빈 곳 – 내려오는 데이터 저장 

 

* Segments – TCP가 주고 받는 단위, 각 segment에 헤더를 붙인다

- out of orders, lost, corrupted -> segment 단위의 재전송이 이루어진다.

- stream of bytes -> segments / 세그먼트들은 바이트들을 실어 나른다.

 

- Full Duplex Service - 양방향 모두 데이터를 주고, 받을 수 있음 + Piggybacking – ACK와 데이터 같이 보내기

- A와 B가 서로 연결 설정 -> 버퍼를 만듦 / 데이터를 주고 받은 이후에는 버퍼 지우기 (연결 해제)

- TCP는 ACK 메커니즘을 통해 데이터가 잘 도착했는지 체크한다. 

 

- Byte number – TCP의 가장 큰 특징, 바이트 단위로 센다, 바이트 수는 에러 검출 및 복구에 사용됨

- 시작 값을 random number 띄움 -> 총 6000 바이트를 1000 바이트 씩 보내고 싶어 

- 1057 sequence number (init) -> 1057이 내가 내보내는 다음 세그먼트의 sequence number 

- 그 다음 segment의 번호는 3057, … 7057 / 지금 보낼 세그먼트의 첫번째 바이트가 sequence 번호가 됨

 

- Acknowledgment number -> 내가 다음에 받아야 할 바이트의 숫자를 ACK로 보낸다.

 

+ TCP 헤더에는 많은 값이 있음 (Source, Destination Port number) Sequence num, ACK num, Window Size, 

- Checksum, Urgent pointer, Options, Control field 등등

 

* Control Field (0 or 1로 한 비트가 세팅 됨) 

* TCP는 connection oriented protocol -> 가상의 길을 뚫는다. (physical X, virtual connection) 

 

* Connection Establish (연결 설정 과정)

1. SYN 비트를 켜서 클라이언트가 서버에게 segment 보낸다 (연결 설정 요청)

2. 서버가 SYN과 ACK 비트를 켜서 클라이언트에게 보낸다 (SYN에 대한 ACK) 

3. 클라이언트가 다시 서버에게 ACK를 보낸다 / 즉, 서로에게 SYN + ACK를 보내어 연결 설정한다. 

-> 이를 악용한 SYN attack 서버를 공격할 수 있음 (매우 많은 SYN segment 서버에게 보내기)

 

* Data Transfer (데이터 전송 과정)

1. 클라이언트가 서버에게 Seq 8001, 9001 두 세그먼트를 보낸다. (data – 8001에서 10000까지) 

2. 서버가 클라이언트에게 잘 받았다는 의미로 10001 (다음 번호)를 ACK로 보낸다 + 본인의 seq 15001 (piggy)

3. 클라이언트는 seq로 10000, ACK로 17001을 보낸다 (서버로부터 15001 ~ 17000까지 받았으니)

+ rwnd (receive window) – 윈도우 사이즈를 보낸다 -> 흐름 제어 flow control

+ Pushing Data – 윈도우가 채워질 때 까지 기다리지 않고, 바로 데이터를 쏘는 것 

+ Urgent Data – 포인터를 활용하여, 세그먼트로부터 데이터를 찾아 바로 위로 (앱에게) 올려준다. 

 

* Connection termination, 연결 해제 

1. 클라이언트가 서버에게 FIN 비트를 켜서 보낸다. 

2. 서버가 FIN + ACK를 클라이언트에게 보낸다.

3. 클라이언트가 서버의 FIN에 대해 ACK를 보내면 연결 해제 완료 

 

* Half Close : 서버는 아직 클라이언트에게 보낼 것이 남았다. FIN 세팅 X, half close 상태 (서버가 ACK만 보냄)

-> 클라이언트가 서버로 데이터만을 못 보내는 것, 서버가 보내는 데이터에 대한 ACK는 보낼 수 있음

 

* Flow control – TCP의 흐름 제어

- 서로 받을 수 있는 rwnd 사이즈를 주고 받는다. (받은 데이터를 바로 위로 보내지 X, 시간이 걸림)

- 클라이언트: ACK가 와 재전송이 필요 없어지면 비우고, 새롭게 늘어난 rwnd 사이즈 보내기

- 서버: 처리한 이후, 새로 늘어난 수신 버퍼 사이즈 (rwnd 사이즈) 보내기 

 

* TCP의 정상적인 동작 

- 바로 응답 X, 타이머가 터진 이후 ACK 나감 + 여러 응답들을 모아서, 7001을 ACK로 보냄, ACK Delaying 

- 메세지 받는 족족 응답을 보내는 것은 비효율 (통신 링크 효율)

- but 대량의 데이터 보낼 때, or 긴급한 메세지 보낼 때에는 통신 효율 떨어짐

 

* Lost segment (데이터가 중간에 날아간 것)

- 기본적으로 selective repeat 활용 (필요한 것만 재전송 요청)

- 시간 안에 ACK 받지 못하면, 재전송 타이머가 터짐 -> 서버가 다 더해서 new ACK를 받으면 재전송 완료 

+ Fast retransmission (빠른 재전송) – 3번 연속 유실된 ACK가 오면 타이머 터지기 전에 재전송 

 

* Lost acknowledgement (ACK가 중간에 날아간 것)

- 서버가 보낸 500 ACK가 중간에 날아가더라도, 500부터 900까지 껴 앉는 ACK가 오면 전혀 상관 X

- ACK가 오지 않아 재전송 타이머가 터지게 되면, 클라이언트로부터 재전송이 이루어짐 

 

+ TCP의 특징 – Slow start, exponential increase (1)

- 한번에 많은 데이터를 보내면 부하가 생길 수 있음 / 중간에 거치는 네트워크의 상황을 알 지 못하니까 

- TCP는 처음에 하나의 segment만 보낼 수 있음 -> congestion window (ACK가 올 때 까지) cwnd가 1로 시작

- ACK를 받음 -> cwnd 2배 (따라서 2개 보낼 수 있음) / rwnd의 한계 내부에서, cwnd 적용 / 1 2 4 8 16 … 

 

(2) Congestion avoidance, additive increase

- 2배로 증가 X, linear하게 congestion window가 1씩 증가 

 

ex) Taho TCP

- 처음에 1, 2, 4, 8 지수 증가 -> 에러 발생 -> 다시 1로 꽝 + 8/2 4가 지수 증가의 한계 threshold

-> 1 2 4까지 증가하고, 이후는 1씩 증가 -> 그러다가 12에서 에러 발생 -> 다시 1로 꽝 + 6까지 지수 증가 

-> TCP의 톱니바퀴, TCP는 올라갔나 내려갔다 쿵쾅 / TCP 전송 속도를 유지할 수 X, 팍팍 떨어트림