TCP와 UDP에 대해 알아BOZA...!
둘의 개념이 어느정도 잡혔는데, 이 둘의 개념이 서로 혼재되기 시작했다...! 그래서, 한번에 티스토리에 한번에 정리해서 내 장기기억 속에 쏙쏙 넣을 계획이다...!
TCP
정의)
1) 서버와 클라이언트 간에 데이터를 신뢰성 있게 전달하기 위해 만들어진 프로토콜
2) TCP(Tansmission Control Protocol, 전송 제어 프로토콜)은 두 개의 호스트를 연결하고 데이터 스트림을 교환하게 해주는 중요한 네트워크 프로토콜이다.
3) 순서대로, 안정적으로, 에러없이 교환할 수 있게 한다.
4) TCP의 신뢰성있는 통신 연결과 종료를 위해 3Way, 4Way Handshake을 사용
특징)
1) 데이터와 패킹이 보내진 순서대로 전달하는 것을 보장
2) TCP의 역할은 에러가 없이 패킷이 신뢰할 수 있게 전달 되었는지 보장해줌.
TCP Header 정보)
| 필드 | 내용 | 크기 |
| 송수신자의 포트 번호 | TCP로 연결되는 가상 회선 양단의 송수신 프로세스에 할당되는 포트 | 16 |
| 시퀸스 번호(Sequence Number) | 송신자가 지정하는 순서 번호, 전송되는 바이트 수를 기준으로 증가 | 32 |
| 응답 번호(ACK Number) | 수신 프로세스가 제대로 수신한 바이트의 수를 응답하기 위해 사용 | 32 |
| 데이터 오프셋(Data Offset) | TCP 세그먼트의 시작 위치를 기준으로 데이터의 시작 위치를 표현(TCP 헤더의 크기) | 4 |
| 예약 필드(Reserved) | 사용을 하지 않지만 나중을 위한 예약 필드이며 0으로 채워져야한다. | 6 |
| 제어 비트(Flag Bit) | SYN, ACK, FIN 등의 제어 번호 | 6 |
| 윈도우 크기(Window) | 수신 윈도우의 버퍼 크기를 지정할 때 사용. 0이면 송신 프로세스의 전송 중지 | 16 |
| 체크섬(Checksum) | TCP 세그먼트에 포함되는 프로토콜 헤더와 데이터에 대한 오류 검출 용도 | 16 |
| 긴급 위치(Urgent Pointer) | 긴급 데이터를 처리하기 위함, URG 플래그 비트가 지정된 경우에만 유효 | 16 |
TCP 세그먼트 )
개요)
- 데이터 스트림(Stream)으로부터 데이터를 받아들여 이것을 청크단위로 분할한 뒤, TCP 헤더를 붙여 TCP 세그먼트를 생성한다.
- TCP 세그먼트는 IP 데이터그램에 패킷화되어 상대방과 주고받게 된다.
- 프로세스는 TCP를 통해 데이터 버퍼를 인수로 넘겨 줌으로써 데이터를 전송한다. TCP는 이 버퍼들을 묶어 세그먼트를 생성하여 인터넷 모듈(IP 등)을 통해 목적지의 TCP로 각각의 세그먼트들을 전송한다.
- TCP 세그먼트는 세그먼트 헤더와 데이터의 두 섹션으로 구성된다. TCP 헤더는 10개의 필수 필드 및 옵션 확장 필드들을 포함한다.
- 헤더 뒤에는 데이터 섹션이 따라 온다. 그 내용은 애플리케이션의 payload 데이터이다. 데이터 섹션의 길이는 TCP 세그먼트 헤더에서 결정되지 않으며, 전체 IP 데이터그램의 길이에서 TCP 헤더와 캡슐화된 IP 헤더의 길이를 뺀 값으로 계산학 도니다, 즉, 데이터 섹션의 길이는 IP 헤더에 의해 결정된다.
Flag 정보)
- TCP Header에는 CONTROL BIT(플래그 비트,6bit)가 존재하며, 각각의 bit는 "URG-ACK-PSH-RST-SYN-FIN"의 의미를 가짐.
- 해당 비트가 1이면, 해당 피킷이 어떤 내용을 담고 있는 패킷인지 나타낸다
Control bit의 의미)
SYN(Synchronize Sequence Number)
- 연결 설정에 사용
- Sequence Number를 랜덤으로 설정하여 세션을 연결하는 데 사용하며, 초기에 Sequence Number를 전송한다.
ACK(Acknowledgement)
- 패킷을 받았다는 응답을 할 때 사용
- Acknowledgement Number가 유효한지를 나타낸다.
- 최초 연결의 첫 번째 Handshake 과정에서는 응답 요청할 필요가 없기 때문에, 최초 연결의 첫 번째 세그먼트를 제외한 모든 Segment의 ACK 비트는 1로 설정한다.
FIN(Finish)
- TCP 연결을 종료할 때 사용한다.
- 더 이상 전송할 데이터가 없음을 의미한다.
- 4-way handshake에서 사용
RST(Reset)
- TCP 연결을 강제로 종료할 때 사용한다
- 비 정상적인 세션 연결 끊기에 해당한다
- 연결을 즉시 끊고자 할 때 사용한다
TCP 프로토콜의 작동 흐름)
1. 연결 생성 (3-way)
2. 자료 전송
3. 연결 종료 (4-way)
TCP의 연결 설정 3-way )
3-way 단계별 설명)
1. SYN (a) 보냄_(client -> server)
Client가 SYN(a) 플래그(너 소켓 연결가능하니?)를 보내 SYN_SENT상태가 되고, Server의 답변을 기다리게 된다.
2. SYN(b) + ACK(a+1) 보냄_(server -> client)
Server는 답변으로 ACK(a+1) 플래그(응 내 소켓 연결 가능해!)를 보내고, SYN(b) 플래그(클라이언트 너도 소캣 연결 가능?)을 보낸다. + Server은 SYN(a+1)을 받아 SYN-RECVED 상태가 된다.
3. ACK(b + 1) 보냄_(client -> server)
Client는 ACK(a+1) 플래그를 통해 통신가능 답변을 받고, Client는 SYN(b)의 답변으로 ACK(b+1) 플래그를 보내어 자신도 통신 준비가 되었다고 알린다. + Client는 ESTABLISHED 상태가 된다.
4. ACK(b +1)받고, 연결 완료...!
Client의 통신 준비완료 메시지를 받은 Server도 ESTABLESHED상태가 되며, 드디어...! 통신을 위한 세션이 맺어지게 된다.
TCP의 연결 종료 4-way)
연결을 종료하기 위한 절차. 4방향 핸드셰이크를 사용한다.
4-way 단계별 설명)
1. FIN 보냄_(client -> server)
Client가 연결 종료를 위해 Server에게 종료했다는 FIN(x) 플래그를 보냄
2. ACK 보냄_(server -> client)
Server가 답변으로 ACK(x+1) 플래그를 보내고, 동시에 자신의 데이터를 모두 보낼 때까지 데이터를 계속 전송한다. 즉, 자신(Server)의 통신이 끝날 때까지 기다린다.
3. FIN 보냄_(server -> client)
자신(Server)의 통신이 끝났음을 알게되면, 서로간의 연결이 종료되었다고 나타내는 FIN(x) 플래그를 보냄
4. ACK 보냄_(client -> server)
Client는 서버의 FIN에 대한 응답으로, 확인메세지(ACK)을 전송하고, 일정 시간 동안(time-wait 상태)해당 연결을 기다린다.
TIME_WAIT 이란? + 발생하는 이유?)
정의)
모든 FIN에 대한 ACK를 받고 연결 종료가 완료된 상태
발생하는 이유)
1) client가 보낸 요청이 유실되었을 때를 대비하기 위해서
클라이언트 입장에서 마지막으로 ACK(y+1)를 보내면 클라이언트가 할 일은 모두 종료된다.
그렇지만, 이때 중간에 마지막 ACK(y+1)이 유실되면 어떡함...?!!!
-> TCP는 신뢰성 보장을 위해 데이터를 보내면 응답을 받아야 되기 때문에, 일정 시간 지나도 응답이 오지 않으면 신뢰성 보장을 위해 다시 재전송한다. (재전송시에는, Server가 FIN을 보내는 것부터 시작..! 사실 서버입장에서는 서버 자신이 보낸 FIN이 없어진건지, 상대방이 보낸 ACK가 없어진 것인지 구별이 불가하기 때문이다.)
만약, 이 상황에서 client가 기다리지 않고 연결을 끊어버렸다면, 다시 보낸 FIN을 처리해줄 Client가 존재하지 않는다.(이미 Close상태로 접어들어 버퍼, 소켓이 모두 제거된 상태이기 때문이다.)
-> 이를 방지하기 위해, client는 2MSL정도 기다린 다음에 연결을 종료한다.
2) 새로운 connection과의 혼재를 위해
client가 서버와 데이터를 교환한 후 종료하고, 새로운 connection을 바로 만들게 될 때, 만약 기존 connection과 같은 포트 번호 사용시 서버 입장에서는 이전 connection의 데이터와 이번 connection의 데이터가 혼재할 시 구별방법이 없다.
-> time wait를 하게 될 시 새로운 connection이 진행되어도 이전 포트는 사용 중이므로 client가 새로운 port number를 할당해 구별할 수 있게 된다.
TCP 패킷의 추적과 관리)
데이터는 패킷 단위로 나누어 목적지(IP계층)으로 전송된다. 예를 들어, A, B, C 패킷이 전송되는 중에 B패킷이 분실되었다. 목적지에는 A와 C만 도착하였지만, 다 도착했다고 착각할 수 있다. 그렇기에 각 패킷에 1, 2, 3과 같은 번호를 부여하여 패킷의 분실 확인과 같은 처리를 하고 목적지에서 재조립
TCP slow start)
혼잡 제어를 위해, 네트워크 혼잡 상태를 파악하고 그 상태를 해결하기 위해 데이터 전송을 제어하는 것을 이야기
네트워크가 정확히 어디에서 어떤 이유로 전송이 느려지는지는 파악하기 힘들지만, 단순히 느려지고 있다고는 확인 가능
그냥 데이터를 보냈는데, 상대방으로부터 응답이 늦게 오거나 안오면 뭔가 문제가 있다는 것을 알 수 있으므로
흐름 제어나 오류 제어 기법들만 사용하다 보면 자연스럽게 재전송이라는 작업이 반복될 수 밖에 없다
이게 한두녀석이 모이다보면, 나도 재전송할꺼야! 가 반복되면서 문제가 발생-> 이를 네트워크 혼잡 붕괴라고 한다
이런 식으로 네트워크의 혼잡 상태가 감지되면, 이러 최악의 상황을 최대한 회피하기 위해 송신 측의 윈도우 크기를 조절하여 데이터 전송량을 강제적으로 줄이게 되는게, 이것이 바로 혼잡 제어이다.
혼잡 제어에는 여러 방법들이 존재.
1) AIMD 방식
늘어날 때는 ws + 1, 줄어들 때는 ws * 0.5 으로 말그대로 "합 증가/ 곱 감소"
장점)
공평한 방식이다..!
예를 들어,
여러 친구들이 이미 네트워크를 점유하고 있는 상태에서 한 친구가 뒤늦게 이 네트워크에 합류했다 생각하면,
당연한 나중에 진입한 쪽의 혼잡 윈도우 크기가 작기 때문에 처음에는 불리하다
그러나 네트워크가 혼잡해지면 혼잡 윈도우 크기가 작은 놈보다 혼잡 윈도우 크기가 큰 놈이 무리하게 데이터를 왕창 보낼려다가 유실될 확률도 크다.
이런 상황이라면 네트워크에 일찍 참여해서 이미 혼잡 윈도우 크기가 큰 놈은 자신의 윈도우 크기를 줄여서 혼잡 상황을 해결하려고 할 것이고, 이 때 남은 대역폭을 활용하여 나중에 들어온 놈들이 자신의 혼잡 윈도우 크기를 키울 수 있다
그런 이유로 시간이 갈수록 네트워크에 참여한 순서와 관계없이 모든 호스트들의 윈도우 크기가 평행 상태로 수렴하게 된다.
단점)
AIMD의 문제점은 네트워크 대역이 펑펑 남아도는 상황에도 윈도우 크기를 너무 조금씩 늘리면서 접근한다는 것이다. 그런 이유로 AIMD 방식은 네트워크의 모든 대역을 활용하여 제대로 된 속도로 통신하기까지 시간이 조금 걸린다.
| TCP | UDP |
| connection-oriented protocol (연결지향형 프로토콜) |
Connection-less protocol (비 연결지향형 프로토콜) |
| Connection by byte stream (바이트 스트림을 통한 연결) |
Connection by message stream (메세지 스트림을 통한 연결) |
| Congestion/ Flow control (혼잡 제어, 흐름 제어) |
No Congestion/ Flow control (혼잡제어와 흐름제어 지원 X) |
| Orderes, Lower speed (순서 보장, 상대적으로 느림) |
Not orderes, Higher speed (순서 보장되지 않음, 상대적으로 빠름) |
| Reliable data transmission (신뢰성 있는 데이터 전송 - 안정적) |
Unreliable data transmission (데이터 전송 보장 X) |
| 일대일(Unicast) 통신 | 일대일, 일대다(Broadcast), 다대다(Multicast) 통신 |
https://evan-moon.github.io/2019/11/26/tcp-congestion-control/
사이 좋게 네트워크를 나눠 쓰는 방법, TCP의 혼잡 제어
혼잡 제어란, 말 그대로 네트워크의 혼잡 상태를 파악하고 그 상태를 해결하기 위해 데이터 전송을 제어하는 것을 이야기한다. 네트워크는 워낙 광대한 블랙박스이기 때문에 정확히 어디서 어
evan-moon.github.io
주요 질문 정리)
Q1. TCP의 연결 설정 과정(3단계)과 연결 종료 과정(4단계)이 단계가 차이가 나는 이유?
client가 데이터 전송을 마쳤다고 하더라도 Server는 아직 보낼 데이터가 남아 있을 수 있기 때문에 일단 FIN에 대한 ACK만 보내고, 데이터를 모두 전송한 후에 자신도 FIN 메세지를 보내기 때문이라고 볼 수 있다.
Q2. Server에서 FIN 플래그를 전송하기 전에 전송한 패킷이 Routing 지연이나 패킷 유실로 인한 재전송 등으로 인해 FIN 패킷보다 늦게 도착하는 상황이 발생하면 어떻게 될까?
위에서 4way handshake과정 마지막 부분에서 말한 TIME-WAIT을 말한 부분이 답이라고 보면되는데, TCP는 이러한 현상에 대비하여 Client는 Server로부터 FIN플래그를 수신하더라도 일정시간동안 세션을 남겨놓고 잉여 패킷을 기다리는 과정을 거친다.
Q3. 초기 Sequence Number인 ISN을 0부터 시작하지 않고 난수를 생성해서 설정하는 이유는?
Connection을 맺을 때 사용하는 포트(Port)는 유한 범위 내에서 사용하고 시간이 지남에 따라 재사용된다. 따라서 두 통신 호스트가 과거에 사용된 포트 번호 쌍을 사용하는 가능성이 존재한다. 서버 측에서는 패킷의 SYN을 보고 패킷을 구분하게 되는데, 난수가 아닌 순차적인 Number가 전송된다면 이전의 Connection으로부터 오는 패킷으로 인식할 수 있다. 이런 문제가 발생할 가능성을 줄이기 위해서 난수로 ISN을 설정한다.
참고)
https://jeongkyun-it.tistory.com/180
TCP와 3-Way, 4-Way Handshake란? (개념/ 동작 방식)
서론 이번 글에서는 TCP의 신뢰성있는 통신 연결과 종료를 위해 3Way, 4Way Handshake의 개념과 통신 동작 방식에 대해 알아보려한다. 이 내용을 이해하기 위해선 TCP의 개념도 알아야해서 간단히 TCP의
jeongkyun-it.tistory.com
'크래프톤 정글 > TIL' 카테고리의 다른 글
| 페이징(Paging)과 페이지 테이블(Page Table)이란? (0) | 2023.12.19 |
|---|---|
| [6주차] Proxy 란? (1) | 2023.11.22 |
| GET 함수 (1) | 2023.11.20 |
| [5주차] Bad file descriptor (0) | 2023.11.18 |
| [5주차] 공부키워드 (0) | 2023.11.13 |
