지난번에 OSI 7계층에 대해서 정리하면서
'시장경쟁에서 TCP/IP모델이 승리했기 때문에 현대의 인터넷은 OSI 모델이 아닌, TCP/IP모델을 따르고 있다.' 라는 말이 있었다.
오늘은 TCP/IP 프로토콜에 대해 아래 링크의 자료를 참고하여 간단히! 알아보겠다.
참고:
TCP/IP 쉽게 이해하기
TCP flag
what is TCP/IP and OSI? // FREE CCNA // EP 3
What is TCP/IP?
[네트워크] TCP/UDP와 3 -Way Handshake & 4 -Way Handshake
TCP/IP가 뭐지?
TCP/IP는 컴퓨터가 서로 소통하기 위해 어떻게 시스템을 디자인 해야할지에 대한 규칙으로, 인터넷 프로토콜 중 가장 많이 쓰이는 IP(Internet Protocol)와 TCP(Transmission Control Protocol)를 함께 부르는 말이다. (Application 계층의 HTTP, FTP, SMTP(데이터를 안정적으로 모두 보내는 것을 중요시하는 프로토콜) 등 TCP를 기반으로 한 프로토콜도 IP위에서 동작하기 때문에, 모두 TCP/IP로 부르기도한다.)
TCP/IP를 사용한다는 것은 송신자가 수신자에게 IP 주소를 사용하여 데이터를 전달하고, 그 데이터가 제대로 갔는지, 너무 빠르지는 않는지, 제대로 받았다고 연락이 오는지에 대한 이야기를 하는 것이다.
위의 사진에서 볼 수 있듯 IP는 Internet 계층에서, TCP는 Transport 계층에서 동작한다.
IP는 패킷 통신 방식의 인터넷 프로토콜이고, TCP는 전송조절 프로토콜인데
IP는 패킷을 목적지에 보내는 데에 집중한다. TCP는 IP위에서 동작하면서 통신하고자 하는 양쪽 단말이 통신 할 준비가 되었는지, 데이터가 제대로 전송됐는지, 데이터가 가는 도중에 변질되지 않았는지, 수신자가 얼마나 받았는지, 빠진 부분은 없는지 등을 점검한다.
TCP는 이런 정보들을 Header에 담는다. 또한 연결을 위해 IP의 정보 뿐 아니라 Port를 이용한다. 예를들어 양쪽 단말이 HTTP로 이루어진 문서를 주고 받을 경우, 데이터 통신을 하려면 80 Port로 연결해야 한다.
3-Way Handshake
'TCP를 기반으로 한다'는 말은 HTTP, FTP, SMTP 같은, TCP의 특성(데이터가 빠지지 않고 제대로 전달 되었는지를 확인하는)을 기반으로 하는 프로토콜이 TCP의 3-Way-Handshake 과정을 거친 후에, 각자 프로토콜에 기반한 교환 과정을 실시한다는 뜻이다.
3-Way Handshake는 신뢰성 있는 통신을 하기 위해 TCP가 연결을 수립하는 과정으로,
데이터를 전송하기 전에 데이터를 주고 받을 준비가 되어있는지 확인한다.
위의 사진은 TCP가 작동하는 과정이다.
- 클라이언트가 서버에게 접속을 요청하는 SYN 패킷을 보내면서 데이터 받을 준비가 되었는지 묻는다.
- 준비가 된 서버는 요청을 수락한다는 표시로 받은 SYN, ACK flag를 설정한 패킷을 클라이언트에게 보낸다.
- 클라이언트는 이 ACK를 다시 서버에게 보낸다. 이후에는 연결이 이루어지고 데이터가 오가게 된다.
여기서 등장하는 'SYN', 'SYN-ACK', 'ACK' Flag는 TCP의 패킷 통신 과정에서 각각의 연결 상태를 표현하거나, 추가적인 정보를 나타내기 위한 표식이다.(이 밖에도 많은 Flag들이 있다.)
각각의 flag에 대해 간단히 적어보았다.
"SYN" : 3-Way Handshake를 성립시키는 첫 번째 과정, 두 단말의 첫 번째 패킷이 이 표시를 갖고 있어야 한다.
"ACk" : 첫번째 패킷을 성공적으로 받았다는 것을 표현해주는 표시로, 3-Way Handshake의 두 번째 과정에서 SYN flag와 함께 수신자가 송신자에게 전송한다.
4-Way Handshake
3-Way Handshake가 TCP가 연결을 수립하는 과정이었다면, 4-Way Handshake는 연결을 종료하기 위해 수행되는 절차이다.
아래 이미지의 왼쪽만 보자. 이 그림이 제일 간결해서 가져와 봤다.
- 연결을 종료하겠다는 의미로, 클라이언트가 서버에게 FIN를 보낸다.(+ACK)
- 서버는 일단 확인메시지(ACK)를 보내고, 지금 하고 있는 통신이 끝날 때 까지 기다린다.
- 통신이 종료되었으면 클라이언트에게 FIN flag를 전송한다.
- 클라이언트 FIN을 받고 확인했다는 메시지(ACK)를 보낸다.
의 과정을 거친다.
만약 Server에서 FIN을 전송하기 전에 패킷을 보냈는데, 지연이나, 재전송으로 인해 그 패킷이 FIN 패킷 보다 늦게 도착하는 상황이 발생할 경우도 있을 수 있다.
이 때 클라이언트가 FIN flag를 받고 바로 세션을 종료하면 느림보패킷은 Drop 되고 데이터가 유실 될 것이다.
이러한 상황에 대비해서 클라이언트는 서버로부터 FIN을 수신 하더라도 일정시간(기본값 240초)동안 세션을 남겨놓고 잉여패킷을 기다리는 과정을 거친다. - 이 과정을 TIME_WAIT이라고 한다.
--- 이런 과정을 통해서 TCP는 신뢰성 있는 통신을 구현하는데,
그래서 시작하고 끝날 때만 이렇게 하는게 다냐고 묻는다면 대답해 드리는게 인지상정
TCP의 다른 특징들
TCP는
1. 흐름제어
2. 혼잡제어 도 한다.
위에서
TCP는 통신하고자 하는 양쪽 단말이 통신 할 준비가 되었는지, 데이터가 제대로 전송됐는지, 데이터가 가는 도중에 변질되지 않았는지, 수신자가 얼마나 받았는지, 빠진 부분은 없는지 등을 점검한다. 그리고 이런 정보들을 Header에 담는다...
라고 말했는데,
송신자는 데이터를 한 번에 얼마나 보낼 수 있는지, 수신자는 어디까지 받았는지 끝없이 확인하고,
TCP Header 내의 'Window size'를 사용해 한번에 주고받을 수 있는 데이터의 양을 정한다.(여기서 window는 '일정량의 데이터'를 말 한다고 한다.) 이를 통해 흐름제어가 이뤄진다.
-> window size는 수신측이 정하고, 자신의 상황에 따라 조절한다. 또한 만일 수신자가 300번째 데이터 까지 받았으면 그만큼 받았다고 송신자에게 받은 데이터 +1 의 숫자를 알려주는데 이를 'Acknowledgment Number'라고 한다. 그리고 이 데이터의 순서번호를 표시한 것이 'Sequence Number'라고 한다.
그리고 데이터가 흐르는 네트워크망의 혼잡을 제어하는 역할도 한다고 하는데, 혼잡제어를 하는 여러가지 방법이 있다고 한다.
그 중 내가 참고한 블로그에서 소개한 방법은 'Slow Start',
송신자가 연결 초기에 데이터 송출량을 낮게 잡고, 수신자의 수신을 확인하며 데이터 송출량을 조금씩 늘리는 것
이라고 한다...
그래서 인터넷에서 영상 다운 받을 때, 초반에 소요시간이 엄청 길게 측정되고, 나중에는 점점 줄어드는건가...? (아닐지도)
대단히 똑똑한 녀석이구나.
이제 http로 고고~!
