TCP와 UDP는 전송 계층에서 사용되는 프로토콜입니다.
TCP는 신뢰성 있는 데이터 전송을 지원하는 연결 지향형 프로토콜입니다. 반면, UDP는 비연결형 프로토콜로, 인터넷에서 서로 정보를 주고 받을 때 정보를 보낸다는 신호나 받는다는 신호 절차를 거치지 않고 보내는 쪽에서 일방적으로 데이터를 전달하는 통신 프로토콜입니다. 그래서 UDP가 TCP보다는 빠르고 네트워크 부하가 적지만, 신뢰성 있는 전송이 중요할 때는 TCP를 사용하는 것이 좋습니다.
클라이언트에서 서버로 어떻게 데이터를 전달할 수 있을까? 서로 다른 구성의 네트워크가 어떻게 데이터를 전달하고 받을 수 있을까? 어떤 규칙이 있을까?

IP(Internet Protocol)
인터넷이 통하는 네트워크에서 데이터를 송수신하는 통신에 대한 규약
한국에서 미국의 친구에게 데이터를 보내기 위해서는 최소한의 규칙이 있어야 한다. 네트워크마다 규칙이 다르면 중간에서 데이터 전송이 멈출 수 있다. 통일된 규칙이 필요한데 그것이 바로 IP(인터넷 프로토콜)


위와 같이 IP 주소를 바탕으로, 데이터를 패킷 단위로 쪼개어 전달하게 된다. 이 때 쪼개는 이유는 커다란 데이터가 네트워크의 대역폭을 너무 많이 차지하면 다른 패킷의 흐름을 막을 수 있기 때문이다. 보통 1500바이트 단위로 쪼갠다고 한다.
이 인터넷 프로토콜만으로는 문제점이 발생하는데 다음과 같다.

- 비연결성 - 패킷을 받을 대상이 없을 때에도 패킷을 전송하여 그 전송이 소실될 수 있다.(상대방의 컴퓨터가 꺼져 있는지도 모르고 그냥 데이터를 전송하게 된다. 꺼져 있어도 데이터를 전송하는 것) 혹은 케이블이 끊기는 등 패킷이 손실될 수 있다.

- 비신뢰성 - 중간에 패킷이 갑자기 사라지면 어떻게 할 것인가, 패킷이 순서대로 오지 않는다면 어떻게 할 것인가?(그 패킷의 순간마다 라우터가 더 빠른 곳으로 보낼 것이기에 도착하는 시간이 달라질 수 있다)
- 프로그램 구분 - 하나의 서버에 두 가지 이상의 작업을 보내면 서버는 이 두 작업을 구분할 수 없다.
TCP(Transmission Control Protocol)
전송을 제어하는 규약으로, 인터넷 상에서 데이터를 보내기 위해 IP와 함께 사용하는 규약
인터넷 프로토콜에서 발생한 단점을 보완하기 위해 나온 것이다. IP에 TCP를 얹어 보완해주는 개념으로 이해하면 된다.
간략히 과정을 살펴보면 다음과 같다.

TCP 특징
- 연결지향적 - 목적지랑 나랑 연결되었는지 확인부터 하고 데이터를 보낸다.(TCP 3 handshake)
- 이 때 이 연결은 가상 연결이다. 논리적으로 연결되었다는 것. 실제로 하나의 루트를 차지하여 연결된 것이 아니라, 그냥 서로 SYN, ACK를 통해 연결되었으니 연결되었다고 우리가 생각하자라는 것. 전용 랜선이 보장되는 것이 아니라는 뜻.
- 데이터 전달 보증 - 누락이 되면 저기서 못 받았네?를 인식하고 다시 보낼 수 있다.
- 순서 보장
- 이러한 이유로 TCP는 신뢰할 수 있는 프로토콜로 불리고, 대부분의 애플리케이션에서 TCP를 사용한다.
- Application 단에서 데이터를 전송하면 TCP단에서 그 데이터를 자른다.(세그멘테이션)
- 만약 세그멘테이션 작업이 없다면, 데이터의 일부분을 빠르게 볼 수 없게 된다. 예를 들면, 100MB의 비디오를 시청하려고 할 때, 세그멘테이션 작업이 없다면 우리는 100MB가 모두 로딩이 되어서야 시청할 수 있게 된다. 하지만 세그멘테이션 작업이 이루어진다면, 비디오의 일부분을 먼저 볼 수 있게 된다. 또한 중간에 끊기게 되면 세그멘테이션 작업이 없었다면 100MB가 모두가 날라갈 수도 있다. 하지만 세그멘테이션 작업이 있다면 중간에 끊기더라도 끊기기 전까지 전송된 데이터는 받을 수 있게 된다.

3 handshake
데이터 유실 없이 신뢰할 수 있는 통신을 하기 위해 서로의 상태를 미리 확인하는 절차

서로 연결됨을 인식하고 나서 데이터를 전송한다. 서버가 SYN + ACK, 즉 2번 단계를 수행하지 않으면 클라이언트는 문제가 있다고 인식하고 데이터를 보내지 않는다. 요즘엔 최적화가 되어서 3번 ACK를 보낼 때 데이터도 같이 전송한다.
다음과 같이 TCP 패킷에 정보가 담겨져 있기에 전달 및 순서 보증이 가능해진다.


TCP Flags
현재의 통신 상태를 표현하는 플래그 역할을 한다.
- CWR (Congestion Window Reduced) : 통신 경로가 혼잡해서 전송량을 줄여줄 것을 알려줌
- ECN(Explicit Congestion Notification) : 통신 경로가 혼잡해서 수신할 수 없을수도 있다는 것을 알려줌
- URG(Urgent) : 긴급 포인터에서 지정한 데이터를 즉시 처리해야 한다는 것을 알려줌
- ACK(Acknowledgement) : 확인 응답 메시지
- PSH(Push) : 수신 데이터를 즉시 애플리케이션 계층에 전달해야 한다는 것을 알려줌
- RST(Reset) : 이상 상황이 발생하여 접속이 강제 중단되었다는 것을 알려준다.
- SYN(Synchronize) : 연결 시작 용도로 사용한다. 연결이 시작될 때 SYN 플래그에 1로 표시함
- FIN(Finish) : 데이터 송신이 완료되어 통신을 종료하고 싶다는 것을 알려줌
Sequence number (32bit)
- 전송되는 데이터의 모든 바이트에는 고유한 일련 번호가 부여된다.
- 일련번호는 송신측에서 수신측에 데이터가 몇번째 데이터인지 알려 주는 역할을 한다.
Acknowledgement number (32bit)
- 다음 세그먼트를 수신할 준비가 되었다는 사실을 알린다.
- 몇 번째 데이터를 수신했는지 송신 측에 알려주는 역할을한다.
Window Size (16bit)
: 수신 측의 윈도우 버퍼 크기를 지정할 때 사용, 0이면 송신 프로세스의 전송 중지
⇒ 얼마나 많은 용량의 데이터를 저장해 둘 수 있는지

이 TCP에서는 데이터를 받으면 잘 받았다고 서버가 응답한다. 즉 응답을 제대로 받지 못하면 데이터를 제대로 전송하지 못했다는 의미이다.

순서가 잘못되어 전송되면 그 잘못된 순서부터 다시 보내라고 한다. 기본적으로! 허나 서버에서 최적화를 할 수는 있을 것이다. 모아두고 순서 정보를 바탕으로 재구성하는 등
TCP를 끊는 과정

UDP

UDP는 왜 나왔을까? TCP는 3 handshake 등 추가되는 단계로 속도가 비교적 느리고, 패킷에 여러가지 정보가 붙어 패킷의 용량 또한 커지게 된다. 그러면 병목 현상도 커질 수 있다.
TCP 이런 전송 계층이 없다면?
순차 전송이 보장되지 않는다.
흐름 문제 - 서버 쪽에서 받은 데이터량이 한계가 되면, 이후 송신 측에서 전송하는 데이터는 누락될 수 있다.

체크섬(checksum)
00110011
11001100
11100110
11111111
11100110
= 111100101
11100110
보수 취하면
00011001 → 체크섬 값
송신 측은 데이터와 체크섬 값을 같이 보내고, 수신 측은 이 데이터와 체크섬 값을 더해 모두 1이면 데이터가 전송 과정에서 변조되지 않았다고 판단한다.