[TCP/IP Networks] 8. TCP Connection Establishment and Termination

1. 개요

TCP (연결형 프로토콜): 종단이 서로 데이터를 송신하기 전에 이들 사이에 연결 확립

=> 확립(establishment) 및 종료(termination)의 절차

2. 연결 확립과 종료

연결 확립 프로토콜

1. [SYN] 요구 측의 종단은 접속하고자 하는 서버의 포트번호와 클라이언트의 초기순서번호(Initial Sequence Number, ISN)를 지정한 SYN 세그먼트를 보낸다.

2. [SYN + ACK] 서버는 서버의 초기순서번호(ISN)를 포함한 자신의 SYN 세그먼트로 응답

+ (클라이언트의 ISN + 1 ACK 보냄 -> 클라이언트의 SYN에 확인 응답)

3. [ACK] 클라이언트는 서버로부터 보내 온 SYN에 대하여 서버의 ISN +  1 ACK로 확인응답을 보내야 한다.

=> 3개의 세그먼트에 의해 연결이 확립, 연결 확립 과정 = three-way handshake

일반적인 연결 종료 프로토콜

1. 능동 폐쇄(active close) 클라이언트; close 호출 -> 해당 연결로 더 이상 보낼 데이터가 없다고 선언

-> TCP는 close 호출 전에 클라이언트에게 처리 요청 받은 보낼 데이터를 모두 보낸 뒤 FIN 송신

2. 수동 폐쇄(passive close) 서버 TCP; 앞의 데이터를 모두 받고 FIN을 수신 -> 응용에 EOF를 전달 -> 연결이 닫힘을 알리고, 클라이언트 TCP에 FIN의 수신을 알림(FIN을 담은 세그먼트의 순서 번호 + 1에 대한 ACK)

3. (active close) 서버; read 함수에서 EOF 리턴 확인 -> "보통" 해당 연결에 대한 close 호출하도록 프로그램

이 경우 FIN 송신

4. (passive close) 클라이언트; FIN 수신 -> FIN 담은 세그먼트의 순서번호 + 1 ACK 보냄

=> 위 종료 프로토콜에서 클라이언트와 서버 바뀌어도 문제 X

(but, 요청-응답 응용; 클라이언트가 먼저 닫는 경우 ↑)

3. 연결 확립의 타임아웃

4. 최대 세그먼트 크기

5. TCP 절반 폐쇄

6. TCP 상태 천이도

7. 재설정 세그먼트

8. 동시 개방

TCP의 상태 천이 다이어그램을 보면, 호스트 A와 호스트 B가 서로 간에 각각 SYN을 보내서 연결을 만드려고 할 수 있음

이 때 TCP 표준은 두 개의 연결을 만드는 것 X, 하나의 연결만이 이루어지도록 설계 O

(OSI는 이 시나리오에서 두 연결 생성)

보통 동시 개방은 이론상의 시나리오였으나, 각각 Network Address Translation(NAT)를 거쳐야 글로벌 인터넷을 사용 가능한 두 호스트가 상호간에 outbound TCP 연결(= peer-to-peer 연결)을 만들 필요가 있을 때 사용

= TCP Hole Punching [RFC5128]

9. 동시 폐쇄

양쪽 종단으로부터 능동적 폐쇄 수행 가능

동시 폐쇄; 일반적인 폐쇄와 같은 수의 세그먼트 교환

10. TCP 옵션

TCP 헤더에 옵션 추가

RFC 793, 1323은 추가적인 TCP 옵션 정의

옵션 유형: kind 값으로 구분

NOP(no operation): 송신측이 필드를 4바이트의 배수가 되도록 채우기 위함

ex. <mss 512, nop, wsclae 0, nop, nop, timestamp 1466647 0>

11. TCP 서버 설계

병행성(concurrent; 동시성) 갖도록 설계

서버; 새로운 연결 요청 도착 -> 연결 받아들임 + 새로운 클라이언트 처리 위한 새로운 프로세스 or 스레드 가동

(병행성 지원하는 TCP 서버의 자원 활용에 대해 논의)

TCP 서버 포트 번호

netstat 옵션

-a: 네트워크상의 모든 종단점 표시

-n: DNS서버 사용 -> IP 주소 dotted decimal로 출력 + 서비스 이름을 숫자로 포트번호 출력

-f inet: TCP와 UDP 종단점만 표시

Sun % netstat -a -n -f inet
Active Internet connections (including servers)
Proto Recv-Q Send-Q  Local Address      Foreign Address      (State)
tcp         0            0       140.252.1.29.23   140.252.1.32.34603 ESTABLISHED
tcp         0            0       140.252.13.33.23 140.252.13.65.1030 ESTABLISHED
tcp         0            0       140.252.13.33.23 140.252.13.65.1029 ESTABLISHED
tcp         0            0        *.23                       *.*                            LISTEN

로컬주소 *.23: 임의의 로컬 인터페이스에서 받아들이는 의미

외부주소 *.*: 외부 IP 주소와 포트를 알지 X, 종단점은 연결의 도착 기다림

LISTEN 상태: 병행서버가 나중에 연결요구를 받아들이기 위해 이용되는 종단점

(멀티홈드 호스트) sun: slip 링크의 인터페이스(140.252.1.29)와 이더넷(140.252.13.33)에 장착

로컬 IP 주소의 제한

서버가 로컬 IP주소를 와일드 카드로 하지 X 경우: 지정된 로컬 IP주소외 연결 거부

Sun % sock -s 140.252.1.29 8888 // 140.252.1.29 IP로 연결 제한

Proto Recv-Q Send-Q  Local Address          Foreign Address      (State)
tcp          0           0       140.252.1.29.8888  *.*                             LISTEN

외부 IP 주소의 제한

TCP 서버가 자신에 대해 확립할 수 있는 제한 형식

lport: 서버의 알려진 포트/ localIP: 로컬 인터페이스의 IP 주소

로컬 주소	외부 주소	설명
localIP.lport localIP.lport *.lport	foreignIP.fport *.* *.*	하나의 클라이언트에 제한(보통은 지원X) 하나의 로컬 인터페이스(localIP)에 도착하는 연결 제한 lport에 보내는 모든 연결 수신

수신 연결 큐(Incoming Connection Queue)

병행 서버: 각 클라이언트를 다루기 위해 새 프로세스 만들 수 있음

listen을 위한 서버: accept 함수 사용 -> 한 개의 연결 요청만을 처리 가능

• 그렇다면, 여러 개의 연결 요청 동시에 들어오면?
• + 연결 설립이 되지 않는 연결 요청으로 공격 받고 있다면? (-> 2판)
• 이런 문제 TCP 어떻게 다루는가?

=> (1) SYN 받았지만 아직 연결 설립되지 않은 연결

or (2) 핸드셰이킹이 끝났지만 listen을 위한 서버가 아직 accept 하지 못한 연결 중 하나

• 운영체제에 포함된 TCP 구현: 각 상황 처리하기 위해 연결 큐 각각 가지고 있음
• 응용은 제한된 문맥에서 두 개의 큐 크기 조절할 수 있음
• (BSD Sockets API: 전통적으로 두 큐의 합 크기 설정 옵션 제공 but, 최신 Linux 커널: 해당 옵션 사용 -> (2) 번 큐의 크기 정함)

<리눅스에서 수신 연결 큐에 관한 규칙>

1. 시스템 파라미터 net.ipv4.tcp_max_syn_backlopt(기본값 1000)이 운영체제에서 수용가능한 SYN 요청 수 결정

2. 각 listening TCP socket은 (2)번 연결에 대한 고정된 크기의 큐 보유, 큐의 크기 = backlog

3. (2)번 연결에 대한 큐에 공간 O -> TCP는 SYN 요청에 대한 ACK를 송신 -> three-way handshake 완료

4. (2)번 연결에 대한 큐에 공간 X -> Linux의 TCP 구현은 SYN에 대한 응답을 지연(독특한 동작) = listening 서버가 accpet 해서 위기를 극복할 거라 생각한 설계

but, 시스템 파라미터 net.ipv4.tcp_abort_on_overflow 설정 O -> 지연 X 바로 RST 세그먼트 보내 연결 중단

 

결국, BSD Sockets API에서 응용이 연결 도착을 알 게 되었을 때(= accept 함수가 연결 소켓 리턴했을 때)

-> 이미 TCP의 three-way 핸드셰이킹이 끝나있는 상태

한편, TCP 클라이언트의 connect 서버는 SYN + ACK 받으면 리턴 

-> 서버가 연결 소켓을 가지게 될 때는 이미 클라이언트가 데이터를 보냈을 수 있음

12. 요약

• TCP 연결확립과 종료 절차
• TCP의 절반 개방 및 종료, 동시개방과 동시종료 절차
• 상태 천이도 ~> TCP 동작 이해
• tcpdump 명령 이용한 TCP의 연결과 종료