[네트워크]TCP에 관하여

TCP
연결지향의 신뢰성있는 바이트스트림 서비스
tcp provides a connection-oriented,reliable,byte-stream service

연결지향이란?
두 호스트가 메세지를 보낼 때, 메세지의 상태 정보를 담고 있는 자료구조를 연결이라 함. 각자가 메세지를 보내고 교환하는 절차가 필요함. 메세지를 보내기 전에 자료구조의 내용을 채움.

신뢰성 서비스
1.정보단위인 세그먼트를 ip로 전송.
데이터를 tcp가 전송하기 적합한 크기(세그먼트 단위)로 나눔.
Udp는 응용이 데이터그램을 적절한 크기로 나눔.
tcp와 udp의 차이점 구분.

2.tcp는 세그먼트를 보낼 때 마다 타이머를 설정
 - ack메세지를 기다림. ack가 없을 경우 세그먼트 재전송.

3.상대편으로 부터 데이터를 받으면 확인 응답을 보냄.

 

4.end to end checksum
 - 헤더와 데이터를 일정 단위로 쪼갠 후 더한 값을 체크해 에러인지 아닌지 확인. 전송 중에 변화되었는지 검출
 - 오류가 난 세그먼트는 버리고 확인 응답을 보내지 않음.

5.ip데이터그램 형태로 전송되어 순서를 지키지않고 수신측에 도착. 수신측 tcp는 데이터를 재정렬해, 정확한 순서대로 응용에 전달.

6.IP는 중복이 발생해도 허용, 수신측은 중복 데이터를 폐기

7.흐름 제어를 제공
 - 각 종단은 유한한 버퍼를 가짐.
 - 수신측 tcp는 버퍼용량을 초과하지 않는 범위의 데이터만 버퍼에 저장.

 

바이트 스트림 서비스
 - 양방향의 8bit byte stream이 교환됨. full-duplex 서비스 제공.(입력,출력 스트림이 독립)
 - 레코드 구분자 삽입 기능 지원x(행 구분자 = 개행)
 - tcp는 바이트에 대한 해석을 전혀 하지 않음.

혼잡 제어가 없는 이유?
 - 혼잡 제어는 응용 계층에 제공하는 서비스가 아님. 서버가 제공하는 자원을 지연없이 사용하기 위한 호스트의 서비스를 혼잡 제어라고 하는데 이는 응용 계층에 제공할 서비스는 아니다.

tcp 헤더
 - 20 바이트. 옵션에 따라 달라짐.
 - 포트 번호 필드 : 송신, 수신 응용을 구분하기 위해서 사용.소켓을 사용. 클라와 서버의 두 소켓을 묶어서 socket pair라고 한다. 소켓 페어는 인터넷 상의 tcp 연결을 유일하게 식별하는데 사용.
 - 순서 번호 필드 : 송신측의 tcp로 부터 수신측의 tcp로 가는 데이터 스트림의 바이트를 구분하기 위해 매 바이테 붙여진 번호.0부터 2^32-1까지 사용. 초과하면 0으로 돌아감. syn플래그가 설정될 경우, 순서 번호 필드에는 호스트가 연결에 선택한 초기순서번호를 기재.(송신측의 시작 번호(초기순서번호)가 정해져있으니 이걸로 먼저보내겠다.)
 - 확인 응답 필드 : 수신한 마지막 바이트의 순서 번호+1을 기재. ack플래그가 설정되어 있을 경우에만 유효.
 - 슬라이딩 윈도우 프로토콜의 일종.
 - 순서상 먼저 도착한 세그먼트나 손상된 세그먼트에 대한 정보를 송신측에 알려주지 않음.

4비트 헤더 길이 필드
 - 헤더의 최대 길이는 60바이트. 일반적으로 20바이트. 

플래그 비트
 - URG 긴급 포인터가 유효함.
 - ack 확인응답 번호가 유효함.
 - psh 수신측은 데이터를 가능한 빨리 응용으로 보내야 함.
 - rst 연결을 재설정
 - syn 연결을 초기화하기 위해 순서 번호를 동기화.
 - fin 송신측이 데이터 전송을 종료.

 

checksum 필드
 - 송신측에서 계산,저장되고 수신측에서 검사.

urgent pointer 필드
 - 잘안씀.

 

TCP 연결 수립 및 종료
연결 확립 방법과 종료의 절차를 다룸.

3way handshaking으로 연결, 4way handshaking으로 종료.

연결 확립 프로토콜
 - syn은 초기순서번호(isn)로 지정. 랜덤하게 설정.
 - syn+ack 서버의 초기순서번호를 포함한 자신의 syn+ack 전송. 클라의isn+1을 응답해 syn에 확인 응답.
 - ack 클라이언트는 서버로부터 보내온 syn에 대해 isn+1로 응답.

연결 종료 프로토콜
active close : 클라이언트가 먼저 close함수 호출.-> 더 이상 연결을 유지할 필요가 없다. 하지만 클라가 close를 호출했다 하더라도 앞에서 전송한 데이터가 모두 보내졌다는 확신X. close가 호출되어도 시간 차가 발생. 클라는 데이터를 모두 보낸 뒤 fin을 전송함.

 

passive close : 서버 tcp는 데이터를 모두 받고 fin을 수신하면 응용에 eof를 전달하여 연결이 닫힘을 알리고, 클라 tcp에 fin의 수신을 알림.fin의 순서번호+1

 

연결 확립의 타임아웃
1.서버가 꺼져있을 때

최대 세그먼트 크기
MSS : maximum segment size
 - tcp가 상대편에 한번에 보낼 수 있는 데이터의 최대 크기
 - 연결이 확립될 때 각 종단은 MSS 통지
 - MSS = MTU -IP헤더 - TCP헤더
 - MTU는 각 연결에 사용된 종단의 인터페이스에 따라 결정됨. -> 필요에 따라 유동적.
 - 종단의 인터페이스에서 사용하는 MTU보다 중간에 다른 인터페이스에서 사용하는 MTU의 크기가 작으면 fragmentation이 필요함.


절반 폐쇄(half close)
 - tcp 연결의 한쪽 종단이 다른쪽 종단으로부터 데이터를 전송 받고 있는 상태에서도 데이터의 출력을 종료할 수 있는 기능. 난 보낼건 없지만 너가 보내면 받아는 주겠다.

 

reset 세그먼트

half-open
A가 B에게 세그먼트를 다로 보내지 않고 연결을 종료 또는 중단.


1.MTU와 MSS의 차이점을 설명하여라.
-MSS는 MTU크기에서 헤더 값을 제외한 실제로 담을 수 있는 데이터의 크기를 의미한다.


2.Active Close와 Passive Close를 비교하면서 설명하여라.
-active close와 passive close의 차이점은 어느쪽이 연결을 먼저 끊으려하는가의 차이이다.

active close는 클라이언트가 더 이상 보낼 데이터가 없다고 판단하여 close함수를 호출하여 서버에게 fin 플래그를 전송한다.
passive close는 서버가 클라이언트로 부터 모든 데이터를 받았다고 하여 fin 플래그를 수신하면 eof를 전달하여 연결이 닫힘을 알리는 방법이다.

3.BSD Sockets API에서는 절반 폐쇄를 위해 shutdown() 함수를 지원한다. 이를 쓸 경우의 장단점을 논하여라.
-close함수의 경우 클라이언트와의 단방향적 연결을 끊지만, shutdown의 경우 내가 원하는 방향을 선택하여 끊을 수 있다는 장점이 있다.

단점으로는 아직 클라이언트 측이 FIN 플래그를 보냈지만, 데이터를 받을수 있는 상태(recive_wait)여서 남은 데이터를 받으려 했더니 이미 shutdown에 의해 연결이 끊긴 상태일 수 도 있다. 이런 경우에는 데이터를 받을 수 없다.

4.TCP 프로토콜을 상세히 설명하는 책에는 TCP의 상태 천이도 (State Transition Diagram)가 제시되어 있는 경우가 많다. 해당 상태는 netstat에서 확인할 수도 있다. 이를 제시하는 이유가 무엇일까? 인터넷 검색을 통해 그 필요성을 조사하여라.
-FIN을 보내고 데이터를 받기 위해 대기 중인 클라이언트와 연결이 종료 됐다고 생각하는 서버와의 갭을 설명하기 위함이라고 생각한다.

5.TCP에서 재설정(reset)을 해야 하는 상황을 하나 설명하여라.
-클라이언트가 오랫동안 서버와 연결을 하지 않다가 다시 접속할 때 연결을 다시 설정하기 위해서 rst를 응답으로 보내 다시 연결한다.

6.TCP에서 Delayed ACK을 사용하는 이유를 설명하여라.
-delayed ack란 수신측에서 패킷을 받앗을 때 바로 ack를 주는 것이 아니라 약간의 지연 후 응답하는 방식이다.

이렇게 함으로서, 데이터와 함께 ack를 같이 보낼 수 있는 효율성이 있다. ack 패킷 전송 횟수를 줄인다는 의미이다.


7. TCP에 포함되어 있는 Nagle의 알고리즘이 어떤 문제를 해결할 수 있는지 설명하여라.

한편, 인터넷에서 검색해보면, 몇몇 온라인 게임을 할 때에 Nagle의 알고리즘을 꺼라고 조언하는 경우들이 있다.

왜 그런 조언을 하는지, 어떤 상황에서 해당 조언이 유효한지 설명하여라.

-nagle`s Algorithm은 tcp를 통해 패킷을 전송할 때, 전송한 패킷에 대한 ack가 올 때까지 기다린 후 다음 패킷을 전송하는 방식이다.

이 알고리즘을 통해 ack가 수신하기 전까지 아직 응답을 받지 못하고 버퍼에서 기다리는 패킷들을 한번에 처리하여 트래픽을 감소시킬 수 있다.

하지만 즉각적인 반응을 주로하는 온라인 게임에 경우 네트워크가 원할하지 못할 경우 응답성이 떨어지는 nagle`s algorithm을 사용하면 즉각적인 반응을 하지 못하기 때문에 사용하지 말라고 조언한다.

예를 들어 FPS와 같은 경우 클릭 이벤트에 대한 응답이 바로 오지않고 기다릴 경우 사용자 입장에서는 딜레이 시간만큼 손해를 볼 수 있다.