IP(Internet Protocol)가 인터넷 프로토콜로서 복잡한 인터넷 망 속에서 클라이언트와 서버 간에 통신 할 수 있게 IP 주소와 패킷과 같은 규칙을 통해 통신을 하게 하는 것이라면,
TCP(Transmission Control Protocol)는 IP 규칙으로만 통신하기에 부족하거나 불안정하던 여러 단점들(패킷 순서가 이상하거나 패킷이 유실)을 커버해, 패킷 전송을 제어하여 신뢰성을 보증하는 프로토콜로 보면 된다.
IP와 TCP 둘 다 프로토콜이지만 이 둘을 동일시로 보면 안된다. 이 둘은 별개의 규칙이다.
IP 규칙에 써있는대로 목적지까지 다다랐으면, TCP 규칙에 써있는대로 올바르게 도착했는지 정확히 누구에게 전달되어야하는지 하나하나 따진다고 생각하면 된다.
TCP와 UDP는 OSI 7계층들 중 TCP/IP의 전송 계층에서 사용되는 프로토콜이다.
※ 전송 계층은 송신자와 수신자를 연결하는 통신 서비스를 제공하는 계층이다.
즉, 데이터의 전달을 담당하며 전달되는 패킷의 오류를 검사하고 재전송 요구 등의 제어를 담당한다.
📌 TCP(Transmission Control Protocol)
TCP는 연결 지향적 프로토콜이다.
※ 연결 지향적 프로토콜은 클라이언트와 서버가 연결된 상태에서 데이터를 주고받는 프로토콜을 의미한다.
TCP의 특징
1. 연결형 서비스로 가상 회선 방식을 제공
• 송신자와 수신자가 데이터를 전송하기 전에 3-way handshaking 과정을 통해 연결을 설정하고,
• 데이터 전송이 끝나면 4-way handshaking 과정을 통해 연결을 해제한다.
2. 흐름 제어(Flow control)
• 수신자의 버퍼 오버플로우(Buffer Overflow)를 방지하기 위해 윈도우 크기(Window Size)를 조절하여 데이터 처리 속도를 관리한다.
3. 혼잡 제어(Congestion control)
• 네트워크 내의 패킷 수가 과도하게 증가하지 않도록 방지
4. 높은 신뢰성 보장
• 데이터가 손실되거나 손상되었을 경우 재전송(재요청)하여 데이터의 무결성을 보장한다.
5. 전이중(Full-Duplex), 점대점(Point to Point) 방식
• 전이중(Full-Duplex) : 전송이 양방향으로 동시에 일어날 수 있다.
• 점대점(Point to Point) : 각 연결이 정확히 2개의 종단점을 가지고 있다.
6. 데이터 순서 보장
• 송신 측에서 데이터를 세그먼트(segment) 단위로 나누어 전송하며, 수신 측에서는 이를 순서대로 재조립한다.
TCP의 전송 제어 기법
TCP(Transmission Control Protocol)는 단어 그대로 원활한 통신을 위해 전송 흐름을 제어하는 기능을 프로토콜 자체에 포함하고 있다. 만약 TCP가 없었더라면 개발자가 일일이 데이터를 어떤 단위로 보낼 것인지 정의해야 하고, 패킷이 유실되면 어떤 예외처리를 해야하는 지까지 신경써야하기 때문에, 덕분에 우리는 온전히 상위의 동작에만 집중할 수 있는 것이다.
보통 TCP의 전송 제어 방법은 다음 3가지로 정리된다.
📵 흐름제어(Flow Control)
• 수신자가 처리할 수 있는 데이터 속도가 다르기 때문에, 송신자가 수신자의 데이터 처리 속도를 초과하지 않도록 데이터를 전송하는 기법
• 수신자의 버퍼 오버플로우를 방지하기 위함
• 슬라이딩 윈도우(Sliding Window) 방식을 사용
⸰ 수신자가 설정한 윈도우 크기만큼의 데이터를 송신자가 전송하도록 조절
⸰ 윈도우 크기는 수신자의 버퍼 여유 공간에 따라 동적으로 변경
📵 오류제어(Error Control)
• 데이터 전송 중 발생한 오류를 감지하고 복구하는 기법
• 데이터의 무결정을 보장하기 위함
• FEC(Forward Error Correction, 순방향 오류 정정) 기법 사용
⸰ 데이터 전송 시, 오류를 스스로 수정할 수 있는 정보를 추가하여 전송하는 방식
• BEC(Backward Error Correction, 후방 오류 정정) 기법 사용
⸰ 데이터 전송 시, 오류가 감지되면 송신자에게 재전송을 요청하는 방식
📵 혼잡제어(Congestion Control)
• 네트워크가 불안정하여 데이터가 원활히 통신이 안되면 제어를 통해 재전송을 하게 되는데, 재전송 작업이 반복되면 네트워크가 붕괴될 수도 있다. 따라서 네트워크 혼잡 상태가 감지되면 송신측의 전송 데이터 크기를 조절하여 전송량을 조절한다.
• 네트워크 혼잡으로 인한 패킷 손실과 지연을 방지하기 위함
• 느린 시작(Slow Start)
⸰ 처음에는 작은 양의 데이터를 보내고, 네트워크 상태를 확인하면서 전송량을 지수적으로 증가시킨다.
• 혼잡 회피(Congestion Avoidance)
⸰ 혼잡이 감지되면 전송 속도를 선형적으로 증가시켜 혼잡을 방지한다.
• 빠른 복구(Fast Recovery)
⸰ 패킷 손실을 빨리 감지하고 복구하여 네트워크 효율을 높인다.
TCP의 연결 및 연결 해제 과정
TCP의 연결 과정 (3-way handshake)
TCP는 신뢰성 프로토콜 답게, 배달 하기전에 목적지가 무사한지 미리 확인하고 배달 끝나고도 또 확인도 해주는 굉장히 친절한 프로토콜이다. 통신을 시작할 때와 종료할 때 서로 준비가 되어있는지를 반드시 미리 먼저 물어보고 패킷을 전송할 순서를 정하고 나서야 본격적인 통신을 시작하기 때문이다.
이러한 과정이 우리가 지겹도록 들은 3 Way Handshake 와 4 Way Handshake 과정이다.
둘 다 똑같은 핸드쉐이크(Handshake)지만, 3 Way는 통신을 시작할 때, 4 Way는 통신을 마칠 때 거치는 과정이라는 차이만 있을 뿐이다.
한마디로 한번 통신하는데 Handshake를 두 번 해서 신뢰가 두텁다 못해 과하게 신뢰성을 보장한다고 생각하면 된다.
위 그림을 보면 클라이언트가 처음 서버와 통신을 하기 위해 TCP 연결을 생성할 때 SYN와 ACK이라는 패킷을 주고 받고, 통신을 종료하는 과정에선 FIN이라는 패킷을 주고 받고 있는 걸 확인 할 수 있다.
단어가 생소하지만 그냥 내가 너한테 전송하였다는 인증 도장 정도로 생각하면 된다.
즉, 패킷 내부에 들어있는 인증 플래그 값들을 확인하여 클라이언트가 서버가 서로 보낸 패킷의 순서와 패킷을 제대로 받았는 지를 검증하는 것이다.
🚩 Flag 종류
| FLAG | 종류 |
| SYN | 접속요청을 할 때 보내는 패킷을 말한다. TCP 접속 시에 가장 먼저 보내는 패킷이다. |
| ACK | 상대방으로부터 패킷을 받은 뒤에, 잘 받았다고 알려주는 패킷을 말한다. 다른 플래그와 같이 출력되는 경우도 있다. |
| PSH | 데이터를 즉시 목적지로 보내라는 의미이다. |
| FIN | 접속 종료를 위한 플래그 이 패킷을 보내는 곳이 현재 접속하고 있는 곳과 접속을 끊고자 할 때 사용한다. |
🤝 TCP Connection (3-way handshake) 과정
3-way handshake를 간단히 표현하면 다음과 같다.
#1. Client -> Server : 내 말 들려?
#2. Server -> Client : 어 잘 들려! 내 말은 들려?
#3. Client -> Server : 잘 들려!
① 클라이언트가 접속을 요청하는 SYN 패킷을 보낸다.
이때 클라이언트는 응답을 기다리기 위해 SYN_SENT 상태로 변한다.
② LISTEN 상태였던 서버는 SYN 요청을 받으면, 클라이언트에게 요청을 수락하는 ACK 패킷과 SYN 패킷을 보낸다.
(서버도 클라이언트에 접속해야 양방향 통신이 되기 때문에)
③ SYN과 응답 ACK를 받은 클라이언트는 ESTABLISHED 상태로 변경하고 서버에 응답 ACK를 보낸다.
④ 응답 ACK를 받은 서버는 ESTABLISHED 상태로 변경되어 데이터 통신이 가능하게 된다.
✉️ 데이터 통신 과정
① Established 된 상태에서 서버에게 데이터를 보낸다.
② 서버는 잘 전송받았다고 ACK 플래그를 넣어 응답한다.
③ 만약 클라이언트가 서버로부터 ACK를 못 받았으면 제대로 송신하지 못한걸로 판단하고 데이터를 재전송을 한다.
🤝 TCP Disconnection (4-way handshake) 과정
4-way handshake를 간단히 표현하면 다음과 같다.
#1. Client -> Server : 나는 다 보냈어! 이제 끊자!
#2. Server -> Client : 알겠어! 잠시만~
#3. Server -> Client : 나도 끊을게!
#4. Client -> Server : 알겠어!
① 먼저 close를 실행한 클라이언트가 FIN을 보내고 FIN-WAIT-1 상태로 대기한다.
② 서버는 CLOSE-WAIT으로 바꾸고 응답 ACK를 전달한다. 동시에 해당 포트에 연결되어 있는 애플리케이션에게 close를 요청한다.
③ ACK를 받은 클라이언트는 상태를 FIN-WAIT-2로 변경한다.
④ close 요청을 받은 서버 애플리케이션은 종료 프로세스를 진행하고 FIN을 클라이언트로 보내 LAST_ACK 상태로 바꾼다.
⑤ FIN을 받은 클라이언트는 ACK를 서버에 다시 전송하고 TIME-WAIT으로 상태를 바꾼다.
TIME-WAIT에서 일정 시간이 지나면 CLOSE 된다. ACK를 받은 서버도 포트를 CLOSED로 닫는다.
※ TIME-WAIT : 먼저 연결을 끊는 쪽에서 생성되는 소켓으로, 혹시 모를 전송 실패에 대비하기 위해 존재하는 소켓이며, TIME-WAIT이 없다면, 패킷의 손실이 발생하거나 통신자 간 연결 해제가 제대로 되지 않을 수 있다.
📌 UDP(User Dataram Protocol)
UDP는 비연결형 프로토콜이다.
※ 연결을 위해 할당되는 논리적인 경로가 없고, 각각의 패킷은 다른 경로로 전송되며, 독립적인 관계를 지닌다.
UDP의 특징
1. 비연결형 서비스로 데이터그램 방식을 제공한다.
• 데이터의 전송 순서가 바뀔 수 있다.
2. 데이터 수신 여부를 확인하지 않는다.
• TCP의 3-way handshaking과 같은 과정 X
3. 신뢰성이 낮다.
• 흐름 제어(flow control)가 없어서 제대로 전송되었는지, 오류가 없는지 확인할 수 없다.
4. TCP보다 속도가 빠르다.
5. 1:1 , 1:N, N:N 통신이 가능하다.
UDP는 비연결형 서비스이기 때문에 연결을 설정하고 해제하는 과정이 존재하지 않는다.
서로 다른 경로로 독립적으로 처리하며, 흐름 제어 또는 혼잡 제어와 같은 기능을 처리하지 않기에 TCP보다 속도가 빠르며 네트워크 부하가 적다는 장점이 있지만, 신뢰성 있는 데이터 전송을 보장하지 못한다.
UDP는 신뢰성보다는 연속성 있는 전송이 필요할 때 사용하는 프로토콜로 예를 들면, 실시간 서비스(streaming)에 자주 사용된다.
TCP VS UDP
각 프로토콜의 특징을 표로 비교해보면 다음과 같다
| 프로토콜 종류 | TCP | UDP |
| 연결 방식 | 연결형 서비스 | 비연결형 서비스 |
| 패킷 교환 방식 | 가상 회선 방식 | 데이터그램 방식 |
| 전송 순서 | 전송 순서 보장 | 전송 순서가 바뀔 수 있음 |
| 수신 여부 확인 | 수신 여부를 확인함 | 수신 여부를 확인하지 않음 |
| 통신 방식 | 1:1 통신 | 1:1 , 1:N , N:N 통신 |
| 신뢰성 | 높다 | 낮다 |
| 속도 | 느리다 | 빠르다 |
참고 문헌
🔗https://inpa.tistory.com/entry/NW-%F0%9F%8C%90-%EC%95%84%EC%A7%81%EB%8F%84-%EB%AA%A8%ED%98%B8%ED%95%9C-TCP-UDP-%EA%B0%9C%EB%85%90-%E2%9D%93-%EC%89%BD%EA%B2%8C-%EC%9D%B4%ED%95%B4%ED%95%98%EC%9E%90
🔗 https://dev-coco.tistory.com/144
🔗 https://www.crocus.co.kr/1362
🔗 https://seongonion.tistory.com/74
