OSI 7계층 - 전송계층(TCP, UDP프로토콜, 그리고 PORT)
위 그림을 보면, Layer1(물리계층)에서 최종적으로 데이터가 전기신호로 변환되기 까지 Layer2(데이터링크계층)과 Layer3(네트워크계층)에서 각각 이더넷헤더, IP헤더가 더해지는 것을 알수 있다. 그것들이 더해지기전 Layer4(전송계층)에서는 TCP Header(또는 UDP 데이터 그램)을 더해서 데이터를 조립하게 된다.
네트워크 계층에서는 라우터를 통해 인터넷망을 통해 A네트워크에서 B네트워크로 데이터를 전송할수 있다고 하였다. 그런데, 네트워크 계층을 통해서는 네트워크 -> 네트워크 전송은 가능하나, 그 데이터는 목적지 ip가 있는 컴퓨터까지 도달할 뿐이지 해당 컴퓨터에 떠 있는 여러 서비스 중 한군데로의 전송은 불가하다. 이를 가능하게 하는 것은 port번호를 통한 분기이고, tcp/udp 프로토콜에서는 포트번호가 사용된다. 아래에서 순차적으로 살펴보고자 한다.
전송계층
전송계층에서는 데이터를 전송하는 목적지가 어떤 애플리케이션인지도 구분할 수 있는 역할을 하고 있다고 하였다. 이는 port번호를 통해 구분한다. 또한 데이터 전송에 있어 오류 여부를 전송전에 또는 전송중간에 확인 할 수 있는 계층을 전송계층이라고 보면 될 것이다. 다만, 오류 여부 확인은 TCP/UDP중에 TCP프로토콜에만 해당된다.
전송계층에서 데이터의 신뢰성과 정확성을 보장해주는 프로토콜은 TCP프로토콜 이다. TCP프로토콜은 아래에서 자세히 다루겠지만, 데이터 수신여부를 상대방에게 체크하는 프로토콜이라고 보면 될 것이다. 지속적으로 check하므로 연결형 통신 부르기도 한다.
전송계층엔 UDP프로토콜이라는 것도 존재한다. 이 프로토콜은 앞서 정의한 전송계층의 정의와 다소 맞지 않을 수도 있는데, UDP 프로토콜에서는 정확성과 안정성보다는 효율성을 강조한다. tcp 통신은 데이터를 정상 수신했는지 여부에 대한 데이터를 지속적으로 주고받아야 하기 때문에, 보내고자 하는 message와는 상관없는 내용을 주고 받아 통신의 속도와 효율성을 저해 할 수 있다.
그런데, udp 통신은 상태 체크를 하지 않고, 필요한 데이터만을 일방적으로 전송하기 때문에 효율성을 높일 수 있다. 또한 상태를 지속적으로 체크할 필요가 없어 네트워크 상호간에 연결이 필요치 않다. 그래서 UDP 프로토콜을 비연결형 통신이라고도 부른다.
TCP 프로토콜
TCP 헤더
tcp프로토콜을 사용할때 붙이는 데이터들을 tcp헤더라 하고, 세그먼트라 부르기도 한다. 세그먼트의 구성요소는 아래와 같고, 중요한 사항들 위주로 살펴보겠다.
| 1)출발지포트(16bit) | 2)목적지포트(16bit) | 3)일련번호(32bit) | 4)확인응답코드(32bit) |
| 5)헤더길이(4bit) | 6)예약영역(6bit) | 7)코드비트(6bit) | 8)윈도우크기(16bit) |
| 9)체크섬(16bit) | 10)긴급포인터(16bit) | 11)옵션 |
표로 그리긴 하였으나, 표와는 상관이 없으며, 1~11번까지 순차적으로 붙어있는 데이터이다. bold 처리한 중요한 값들 위주로만 살펴보겠다.
출발지포트, 목적지포트
port번호는 한 서버내에서 서로 다른 애플리케이션을 구분짓는 용도로 사용된다. TCP헤더에 포트를 명시함으로서, 애플리케이션까지 구분지어 통신할 수 있도록 하는 것이다. 상대방의 목적지 포트번호를 모르면 통신대상 컴퓨터까지는 도달하겠지만, 구체적인 특정서비스로는 데이터를 전송할 수 없게 될 것이다.
*클라이언트가 웹브라우저라면 웹브라우저의 출발지port는 임의로 할당된다.
port번호 체계
포트번호는 0~65535번까지 사용가능하도록 되어 있다. 이 중 0~1023번 포트는 주요 프로토콜이 미리 예약되어 있다. 1024는 사용하지 않는 포트이고 1025이상부터 사용자가 사용가능한 포트이다. 예약된 포트를 well-know-port(잘 알려진 포트)라 부른다.
| WELL-KNOWN-PORT | |
| SSH (원격접속관련) | 22 |
| FTP (파일전송관련) | 20, 21 |
| TELNET (원격접속관련) | 23 |
| SMTP (전자메일 관련) | 25 |
| DNS (네임서버관련) | 53 |
| HTTP, HTTPS | 80, 443 |
일련번호와 확인응답코드
데이터의 양이 많을때는 데이터를 분할해서 보내야 하는데, 데이터를 나누어 보내기 위한 넘버링이라고 이해하면 될 것이다. 확인 응답코드는 수신자가 응답받았음을 알리는 것이다. TCP통신의 기본인 연결형 통신은 이런식으로 송신에 대한 수신응답을 항상 보냄을 알수가 있다. 자세한건 아래의 코드비트에서 살펴보겠다.
코드비트
앞서 말한바와 같이 TCP프로토콜은 연결형 통신이기에, 두 네트워크가 서로 연결이 되어 있어야 하고, 코드비트에서는 두 네트워크가 서로 연결됐는지를 특정 비트를 주고 받으면서 연결이 됐는지를 확인한다. 6비트로 구성된 코드비트는 총6가지 상태값이 구성되지만, 여기서는 중요한 SYN, ACK, FIN정도만 살펴보겠다.
SYN 연결을 허가받기 위한 요청
ACK 연결을 확립하는 응답
FIN 연결을 종료하기 위한 요청
컴퓨터 A가 B와 연결을 맺고자 할때 먼저 SYN 코드비트를 담은 패킷을 보내고, B는 연결을 확립하겠다는 ACK를 응답으로 보낸다. 그런데, 이는 A입장에서의 연결이므로, B또한 ACK에 SYN 패킷을 더해 보내게 된다. 그러면 이번엔 A가 ACK를 B에게 응답을 보내주어, 상호간에 연결이 확립되게 된다.
A -> (SYN) -> B
B -> (ACK, SYN) -> A
A -> (ACK) -> B
이러한 3번의 패킷 교환이 이루어지게 되고, 이를 3 way handshake라 부른다.
연결을 종료할때도 패킷을 교환하고 이때 연결종료요청(FIN)과 ACK를 상호간에 주고 받게 된다. 이는 3way는 아니고, 4way로 구성된다는 정도만 알고 넘어가자.
윈도우 크기
앞서 말한 일련번호의 경우 데이터 양이 많아지면, 수신자입장에서는 일련번호를 매겨 들어오는 데이터에 대해 매번 확인응답을 해야하는 문제가 있다. 그래서 마치 파일버퍼에 데이터를 한꺼번에 담아 파일을 read하듯이, 버퍼에 송신자가 보내온 데이터를 담아두고 처리하게 된다.
이 버퍼 크기의 한계를 윈도우크기라 말하고, 버퍼의 한계를 넘어버리는 것을 오버플로라 한다. 이 윈도우의 크기는 수신자마다 다를 것이므로, 앞서 말한 3 way handshake 시에 윈도우 크기를 상호간에 확인하게 된다.
UDP 프로토콜
UDP프로토콜은 앞서 말한바와 같이 효율성을 중시하는 프로토콜이라, handshake를 통해 상대방의 상태를 세세하게 체크하지 않는다. 그러므로 UDP 헤더 또한 심플하다.
UDP헤더는 출발지포트, 목적지포트, 길이, 체크섬 정도로 구성된다. 이를 UDP 데이터 그램이라 한다.
UDP프로토콜 같은 경우엔 속도를 중시 여기는 동영상 전송 또는 수신자의 상태를 체크할 필요가 없어 상대를 특정하지 않는 네트워크로의 브로드캐스트 등의 용도로 사용된다. 빠른 전송, 일괄전송하는데 유리한 프로토콜이라 이해해도 좋을 것이다.