전송 계층
Last updated
Last updated
물리 계층, 데이터 링크 계층, 네트워크 계층이 있으면 목적지에 데이터를 보낼 수 있지만, 데이터가 손상되거나 유실되더라도 3개 계층에서는 아무것도 하지 않는다. 그래서 필요한게 전송 계층이다. 전송 계층은 목적지에 신뢰할 수 있는 데이터를 전송하기 위해 필요하다.
오류 점검 기능 : 오류 발생시 데이터 재전송
전송된 데이터의 목적지가 어떤 애플리케이션인지 식별하는 기능
즉, 신뢰할 수 있는 데이터를 순차적으로 전달하는 역할을 하므로, 상위 계층이 데이터 전달의 유효성이나 효율성을 신경쓰지 않도록한다. 또한, 데이터가 중복되거나 누락되지 않고 오류 없이 순서에 맞게 전송되도록 관리한다.
신뢰성/정확성 : 데이터를 목적지에 문제없이 전달하는 것
연결형 통신 : 상대편과 확인하면서 통신
신뢰할 수 있고, 정확한 데이터 전송이 필요한 애플리케이션
프로토콜 : TCP
효율성 : 데이터를 빠르고 효율적으로 전달하는 것
비연결형 통신 : 상대편을 확인하지 않고, 일방적으로 데이터 전송
효율적인 데이터 전송
ex) 동영상
프로토콜 : UDP
신뢰성과 정확성을 우선으로 하는 연결형 통신의 프로토콜이다.
TCP 헤더 : TCP로 전송할 때 붙이는 헤더
목적지까지 데이터를 제대로 전송하기 위해 필요한 정보를 가지고 있다.
세그먼트(segment) : TCP 헤더가 붙은 데이터
데이터를 전송 하기 위해서는 연결(connection)이라는 가상의 독점 통신로를 확보해야, 데이터를 전송할 수 있다. 헤더에서 예약 다음의 코드비트를 보면 다음과 같다.
코드 비트(6bit) : 연결의 제어 정보가 기록, 초깃값은 0이고, 비트가 활성화 되면 1
URG | ACK | PSH | RST | SYN | FIN |
0 | 0 | 0 | 0 | 0 | 0 |
SYN : 연결 요청
ACK : 확인 응답
연결은 아래와 같이 SYC와 ACK를 사용해 확립할 수 있다. 신뢰할 수 있는 연결을 하려면, 데이터 전송전에 패킷 교환을 3번 한다.
컴퓨터1에서 컴퓨터2로 연결 확립 허가를 받기 위한 요청(SYN)을 보낸다.
URG | ACK | PSH | RST | SYN | FIN |
0 | 0 | 0 | 0 | 1 | 0 |
컴퓨터2에서 컴퓨터1이 보낸 요청을 받은 후 허가한다는 연결 확립 응답(ACK)를 보내며, 컴퓨터2도 컴퓨터1에 연결 확립 요청(SYN)을 보낸다.
URG | ACK | PSH | RST | SYN | FIN |
0 | 1 | 0 | 0 | 0 | 0 |
컴퓨터2의 요청을 받은 컴퓨터1이 컴퓨터2로 요청을 허가한다는 연결 확립 응답(ACK)를 보낸다.
URG | ACK | PSH | RST | SYN | FIN |
0 | 1 | 0 | 0 | 0 | 0 |
다음과 같이 데이터를 보내기 전에 연결을 확립하기 위해 패킷 요청을 3번 교환하는 것을 3-way 핸드셰이크(handshake)라 한다.
데이터를 전송한 후에는 연결을 끊기 위한 요청을 해야한다.
FIN : 연결 종료
컴퓨터1에서 컴퓨터2로 연결 종료 요청(FIN)
URG | ACK | PSH | RST | SYN | FIN |
0 | 0 | 0 | 0 | 0 | 1 |
컴퓨터2에서 컴퓨터1로 연결 종료 응답(ACK)
URG | ACK | PSH | RST | SYN | FIN |
0 | 1 | 0 | 0 | 0 | 0 |
컴퓨터2에서 컴퓨터 1로 연결 종료 요청(FIN)
URG | ACK | PSH | RST | SYN | FIN |
0 | 0 | 0 | 0 | 0 | 1 |
컴퓨터1에서 컴퓨터2로 연결 종료 응답(ACK)
URG | ACK | PSH | RST | SYN | FIN |
0 | 1 | 0 | 0 | 0 | 0 |
3-way 핸드셰이크 종료 후, 실제 데이터를 보내거나 받을 때는 TCP 헤더의 일련번호(sequence number)와 확인 응답 번호(acknowledgement number)를 사용한다.
일련번호 : TCP는 데이터를 분할해서 보내는데 송신 측에서 수신 측에 이 데이터가 몇번째 데이터인지 알려주는 역할
확인 응답 번호 : 수신 측이 몇 번째 데이터를 수신했는지 송신측에 알려주는 역할
다음 번호의 데이터를 요청하는 경우에도 사용된다.
10번 데이터 수신 후, 11번 데이터를 송신측에 요청하는데, 이를 확인 응답이라 한다.
예를 한가지 살펴볼 것이다.
데이터 전송 전 3-way 핸드셰이크에서 연결 수립시, 통신에서 사용하는 일련번호와 확인 응답번호가 결정된다.
컴퓨터1은 컴퓨터2로 200바이트 데이터 전송
컴퓨터2는 200바이트 데이터 수신하고, 다음에 수신하고 자하는 데이터 번호(3001 + 200 = 3201)를 확인 응답번호에 넣어 전달.
컴퓨터1은 컴퓨터2로 3201부터 200바이트 데이터 전송
컴퓨터2는 200바이트 데이터 수신하고, 다음에 수신하고 자하는 데이터 번호(3201 + 200 = 3401)를 확인 응답번호에 넣어 전달.
이 과정을 데이터 전송이 완료될 때까지 반복한다.
일련번호와 확인 응답 번호를 사용해 데이터가 손상되거나 유실된 경우에 데이터를 재전송하게 되어있으며, 이를 재전송 제어라고 한다. 즉, 데이터 전송 중 오류가 발생하면 일정시간 대기 후 재전송을 한다.
위에서 설명한 방식은 세그먼트(데이터) 하나를 보낼 때 마다 확인 응답을 한 번 반환하고 있는 통신이다. 하지만 이 통신 방법은, 데이터를 보낼 때마다 매번 응답을 반환하는 방식이기때문에 효율이 높지 않다. 매번 확인 응답을 기다리는 대신 세그먼트를 연속해서 보내고 난 다음 확인 응답을 반환하면, 효율이 높아진다.
이때, 받은 세그먼트들을 일시적으로 보관하는 장소, 버퍼(buffer)가 있으며, 버퍼 덕분에 세그먼트를 연속해서 보내도 수신측은 대응할 수 있다. 또한, 확이 인 응답의 효율도 높아진다. 하지만, 너무 많은 데이터를 보내면, 오버플로(overflow)가 발생할 수 있다.
오버플로가 발생하지 않도록 버퍼의 한계크기를 알고 있어야 하는데, TCP 헤더의 윈도우크기가 버퍼의 한계 크기 값이다. 즉, 윈도우 크기는 얼마나 많은 용량의 데이터를 저장해둘 수 있는지이며, 다시말해 확인 응답을 일일히 하지 않고 연속해서 송수신할 수 있는 데이터 크기이다.
윈도우 크기는 3-way 핸드셰이크시 판단한다.
컴퓨터1의 윈도우 크기를 연결 확립 요청시 전달
컴퓨터2의 연결 확립 응답 + 연결 확립 요청시 컴퓨터2 윈도우 크기 전달
윈도우 크기를 알고 있으면, 확인 응답을 기다리지 않고 세그먼트를 연속해서 보내면 위 그림과 같이 연속으로 보낼 수 있다.
목적지가 어떤 애플리케이션인지 구분하기 위해 TCP 헤더의 출발지 포트 번호와 목적지 포트 번호가 필요하다. 즉, TCP 헤더에 포트 번호가 있기 때문에 애플리케이션을 구분할 수 있다.
포트 번호 : 0 ~ 65535번 사용 가능
well-kwon ports(0~1023 포트) : 주요 프로토콜이 사용하도록 예약되어 있음
서버 측 애플리케이션에서 사용
1024 포트 : 예약되어 있지만, 사용되지 않는 포트
random ports(1025~) : 클라이언트 측 송신 포트
잘 알려진 포트
포트 | TCP | UDP | 설명 | 상태 |
0 | UDP | 예약됨; 사용하지 않음 | 공식 | |
1 | TCP | TCPMUX (TCP 포트 서비스 멀티플렉서) | 공식 | |
7 | TCP | UDP | ECHO 프로토콜 | 공식 |
9 | TCP | UDP | DISCARD 프로토콜 | 공식 |
13 | TCP | UDP | DAYTIME 프로토콜 | 공식 |
17 | TCP | QOTD (Quote of the Day) 프로토콜 | 공식 | |
19 | TCP | UDP | CHARGEN (Character Generator) 프로토콜 - 원격 오류 수정 | 공식 |
20 | TCP | 공식 | ||
21 | TCP | 공식 | ||
22 | TCP | 시큐어 셸 (SSH, Secure SHell) - ssh scp, sftp같은 프로토콜 및 포트 포워딩 | 공식 | |
23 | TCP | 텔넷 프로토콜 (Telnet Protocol) - 암호화되지 않은 텍스트 통신 | 공식 | |
24 | TCP | 개인메일 시스템 | 공식 | |
25 | TCP | 공식 | ||
37 | TCP | UDP | TIME 프로토콜 | 공식 |
49 | UDP | TACACS 프로토콜 | 공식 | |
53 | TCP | UDP | 공식 | |
67 | UDP | 공식 | ||
68 | UDP | 공식 | ||
69 | UDP | 공식 | ||
70 | TCP | [고퍼 프로토콜 (Gopher Protocol)](https://ko.wikipedia.org/wiki/고퍼_(프로토콜)) | 공식 | |
79 | TCP | Finger 프로토콜 | 공식 | |
80 | TCP | UDP | HTTP (HyperText Transfer Protocol) - 웹 페이지 전송 | 공식 |
88 | TCP | 커베로스 - 인증 에이전트 | 공식 | |
109 | TCP | 공식 | ||
110 | TCP | 공식 | ||
111 | TCP | UDP | RPC (Remote Procedure Call) | 공식 |
113 | TCP | 공식 | ||
119 | TCP | NNTP (Network News Transfer Protocol) - 뉴스 그룹 메시지 가져오기에 사용 | 공식 | |
123 | UDP | NTP (Network Time Protocol) - 시간 동기화 | 공식 | |
139 | TCP | 공식 | ||
143 | TCP | 공식 | ||
161 | UDP | SNMP (Simple Network Management Protocol) - Agent 포트 | 공식 | |
162 | UDP | SNMP - Manager 포트 | 공식 | |
179 | TCP | BGP (Border Gateway Protocol) | 공식 | |
194 | TCP | IRC (Internet Relay Chat) | 공식 | |
220 | TCP | |||
389 | TCP | LDAP (Lightweight Directory Access Protocol) | 공식 | |
443 | TCP | HTTPS - 보안 소켓 레이어 (SSL, Secure Socket Layer) 위의 HTTP (암호화 전송) | 공식 | |
445 | TCP | 공식 | ||
445 | UDP | Microsoft-DS SMB 파일 공유 | 공식 | |
465 | TCP | 비공식, 충돌 | ||
514 | UDP | syslog 프로토콜 - 시스템 로그 작성 | 공식 | |
515 | TCP | LPD 프로토콜 - 라인 프린터 데몬 서비스 | 공식 | |
540 | TCP | UUCP (Unix-to-Unix Copy Protocol) | 공식 | |
542 | TCP | UDP | 상용 (Commerce Applications) (RFC maintained by: Randy Epstein [repstein at host.net]) | 공식 |
587 | TCP | 공식 | ||
591 | TCP | 파일메이커 6.0 Web Sharing (HTTP Alternate, see port 80) | 공식 | |
631 | TCP | 인터넷 프린팅 프로토콜 | 공식 | |
636 | TCP | 공식 | ||
666 | TCP | 공식 | ||
873 | TCP | rsync 파일 동기화 프로토콜 | 공식 | |
981 | TCP | SofaWare Technologies Checkpoint Firewall-1 소프트웨어 내장 방화벽의 원격 HTTPS 관리 | 비공식 | |
990 | TCP | 공식 | ||
992 | TCP | 공식 | ||
993 | TCP | 공식 | ||
995 | TCP | 공식 |
다음과 같이 애플리케이션은 각각 포트 번호가 있어서 다른 애플리케이션과 서로 구분된다. 데이터 전송 시 상대방 IP주소가 필요하지만, 어떤 애플리케이션이 사용되고 있는지 구분하려면 포트 번호가 필요하다. 그렇기 때문에, 포트 번호 없이 통신시 컴퓨터에 데이터가 도착하더라도 애플리케이션까지 전달할 수 없다. 이때, 웹 브라우저 접속시 웹 브라우저에는 임의의 포트가 자동으로 할당 된다. 그렇기때문에 서버 측에서는 포트 번호를 정해둬야하지만, 클라이언트 측은 정하지 않아도 된다.
비연결형 통신
효율성을 중요하게 여기는 프로토콜
데이터를 효율적으로 빠르게 보내는 것
스트리밍 방식으로 전송하는 곳에 사용 ex) 동영상 서비스
올바른 목적지의 애플리케이션으로 데이터를 전송하기 위해 필요한 정보가 기록되어있다.
UDP 데이터그램 : UDP 헤더 + 데이터
UDP는 신뢰성과 정확성이 필요하지 않아 위 정보만으로도 충분하다.
TCP는 신뢰성과 정확성을 요구하기 때문에 여러번 확인 응답을 보내면서 전송하지만, UDP는 효율성과 빠른 속도가 중요하므로, 상대방을 확인하지 않고 연속으로 데이터를 전송한다.
UDP를 사용하면, 랜에 있는 컴퓨터나 네트워크 장비에 데이터를 일괄로 보낼 수 있다. 이렇게 일괄로 데이터를 보내는 것을 브로드캐스트라고 한다. TCP는 3-way 핸드셰이크와 같이 데이터 전송시에도 확인 응답을 보내야하기 떄문에, 브로드캐스트와 같이 불특정 다수에게 보내는 통신에는 적합하지 않다.
