TCP / IP 4계층에 대해 알아보기

TCP/IP는 개발 공부를 하면 정말 정말 많이 나오는 소재중 하나입니다!

근데 볼 때마다 정말 새롭고 생소하고 어렵습니다 ㅎㅎ 그래서 이참에 조금 더 자세히 내용을 정리해볼까 합니다!

 

계층 구조

TCP/IP 계층은 네 계층으로 이루어져 있으며 OSI 7계층과 많이 비교되곤 합니다.

TCP/IP는 어플리케이션 계층(L4, 응용 계층), 전송 계층(L3), 인터넷 계층(L2), 링크 계층(L1)으로 이루어져 있습니다.

이 계층들은 특정 계층이 변경되었을 떄 다른 계층이 영향을 받지 않도록 설계되어 있습니다.

 

어플리케이션 계층

어플리케이션 계층은 FTP,HTTP,SMTP,DNS,SSH 등 응용 프로그램이 사용되는 프로토콜 계층입니다. 즉, 웹서비스, 이메일 등 응용 프로그램 간에 데이터를 주고받으며 사용자에게 서비스를 제공하는 계층입니다.

 

전송 계층

전송 계층은 송신자와 수신자를 연결하는 통신 서비스를 제공합니다. 연결 지향 데이터 스트림 지원, 신뢰성, 흐름 제어를 제공합니다. 그리고 어플리케이션과 인터넷 계층 사이의 데이터가 전달딜 때의 중계 역할을 합니디. Segment 단위로 데이터를 전송하며 Port가 전송 주소가 됩니다. 그리고 게이트 웨이 장비를 통해 동작합니다. 대표적인 예로 TCP, UDP가 있습니다.

 

TCP

연결지향 프로토콜을 사용해서 패킷 사이의 순서를 보장하고  신뢰성을 구축해 수신 여부를 확인합니다. 이러한 방식은 가상회선 패킷 교환 방식으로 이루어집니다. 가상회선 패킷 교환방식이란 패킷을 전송하면 패킷들은 전송된 순서대로 도착하는 방식을 의미합니다

TCP의 연결 성립 과정 : 3WAY-HANDSHAKE 참조

TCP의 연결 해제 과정 : 4WAY-HANDSHAKE 참조

 

UDP

UDP는 순서를 보장하지 않고 수신 여부도 확인하지 않으며 단순히 데이터만 주는 데이터그램 패킷 교환 방식을 사용합니다. 그래서 데이터그램 패킷 교환 방식은 패킷들이 독립적으로 이동하여 최적의 경로를 선택해 움직여 순서가 다르게 도착할 수 있습니다. 

 

 

 

인터넷 계층

인터넷 계층은 장치로부터 받은 네트워크 패킷을 IP 주소로 지정된 목적지까지 정확하게 전달되도록 하는 계층입니다. 패킷 단위로 데이터를 구성하여 주고받으며 라우터를 활용하여 최적의 경로를 설정합니다. 대표적으로 IP,ARP,ICMP 등이 있으며 패킷을 수신해야 할 상대의 주소를 지정해 데이터를 전달합니다. IP의 경우 비연결성(패킷을 받을 대상이 없어도 전송), 비신뢰성 (패킷이 손실되거나 순서가 바뀐다)의 단점이 있습니다. 하지만 이를 전송 계층에서 3 WAY HANDSAKE로 해결할 수 있습니다. 

 

링크 계층

전선, 광섬유,무선 등으로 실질적으로 데이터를 전달하며 장치 간에 신호를 주고받는 규칙을 정하는 계층입니다. 이 계층은 물리 계층과 데이터 링크 계층으로 나누는데, 물리 계층은 무선 LAN과 유선 LAN을 통해 0과 1로 이루어진 데이터를 보내는 계층을 말하며, 데이터 링크 계층은 이더넷 프레임을 통해 에러확인, 흐름제어, 접근 제어를 담당하는 계층을 의미합니다.

 

계층간 데이터 송수신 과정

HTTP를 통해 웹 서버에 있는 데이터를 요청한다면 다음과 같은 과정을 따릅니다.

L4 -> L3 -> L2 -> L1 -> (전송하는 쪽) L1 -> L2 -> L3 -> L4 (수신하는 쪽)

어플리케이션 계층에서 전송 계층으로 요청 값들이 캡슐화 과정을 거쳐 전달하고, 다시 링크 계층에서 해당 서버와 통신하고 해당 서버의 링크 계층으로부터 어플리케이션 계층까지 비캡슐화 과정을 거쳐 데이터가 전송됩니다.

 

캡슐화

캡슐화는 상위 계층의 헤더와 데이터를 하위 계층의 데이터 부분에 포함시키고

해당 계층의 헤더를 삽입하는 과정을 의미합니다.

 

https://velog.io/@seonja/%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC-%EA%B5%AC%EC%A1%B0-OSI7-Layer-TCPIP-%EC%BA%A1%EC%8A%90%ED%99%94

1. 어플리케이션 계층의 데이터가 전송 계층으로 전달되는 과정에서 (세그먼트, 데이터그램화) 되면서 TCP 헤더(L4)가 붙여지면서 전송 게층으로 이동합니다.

2. 전송 계층에서 인터넷 계층으로 가는 경우에는 IP(L3) 헤더가 붙으며 패킷화가 됩니다.

3. 인터넷 계층에서 링크 계층으로 가는 경우에는 프레임 헤더와 트레일러가 붙어 프레임화가 됩니다.

 

그리고 이는 비캡슐화 과정을 거쳐 역순으로 진행됩니다. 

 

비캡슐화

하위 계층에서 상위 계층으로 헤더 부분을 제거하는 과정을 의미합니다.

프레임 -> 패킷 -> 세그먼트,데이터그램 -> 메시지 

 

최종적으로 사용자에게 어플리케이션의 PDU(Protocol Data Unit)인 메시지로 전달됩니다.

 

애플리케이션계층 : 메시지

전송계층 : 세그먼트(TCP) 데이터그램(UDP)

인터넷 계층 : 패킷

링크 계층 : 프레임 ,비트

 

+ 예시를 통한 재이해 및 추가 지식

 

상황 예시 

클라이언트가 있고 서버가 하나씩 있는 상황에서 파일을 하나 보낸다.

 

서버의 입장

소켓을 열어 클라이언트와 소통 중인 상황이다.

서버는 파일에 읽고 쓰기가 가능하다, 파일은 HDD에 저장되어 있는 상태,파일 시스템이 있고 Driver가 있고 서로 소통하는 구조

 

서버에 메모리를 할당하는데, 파일의 크기가 메모리보다 큰 경우 메모리가 읽을 수 있는 크기만큼 메모리에 가져온다. 그러면 그 크기만큼 데이터를 읽기 시작한다(read) 이때 메모리는 크기가 작으므로 버퍼가 일어난다. (첫번째 버퍼)

 

아까 언급한 소켓은 TCP/IP를 추상화한 것이다. 소켓에 맞닿는 지점에서는 분해가 일어나는데 TCP 부분에서도 메모리처럼 버퍼가 발생한다 (두번째 버퍼) 그리고 메모리에서는 TCP로 버퍼가 일어난다. TCP에서 IP로 데이터가 넘어가면서 정보를 잘게 쪼갠다 (Segment단위)

 

중간 정리

첫번째 버퍼에서는 데이터를 읽고 있다는 의미에서 버퍼가 발생,

두번째 버퍼에서는 segment단위로 잘게 쪼개고 있는 만큼 전송이 되고 있는 것을 의미한다.

 

여기서 분해가 일어날 때, 세그먼트에 번호를 붙여주고  패킷에 이 세그먼트(L3)를 담는다.

패킷은 택배 박스에 비교해서 생각하면 좋다. 이 패킷(택배 박스,L2)도 옮길 수 있는 수단이 필요한데,

이는 프레임(L1)으로 옮기는 것이다. 그리고 그 프레임은 여러개의 프레임을 갈아타며 클라이언트 쪽에 도착한다.(NIC)

 

그리고 클라이언트 쪽에도 다시 NIC, driver ip, tcp가 존재한다. PC프로그램의 소켓도 존재한다. 

소켓의 본질은 곧 파일이다. 파일에 연결된 버퍼가 있다.(file I/O Buffer)

 

프레임에서 비캡슐화가 일어나면서 Segment가 나오고 Segment는 TCP까지 가서 버퍼가 발생한다.

이 Segment가 2개까지 오면 조립을 하는데, 이 과정에서 이것들을 잘 받았다고 서버에 메시지를 보낸다.

(메세지 내용 : 3번을 보내달라 = acknowledgement window size 포함)

 

서버는 이 상황에서 segment 1, 2번을 보내고 ack3번 메세지를 대기하고 있다.

ack를 받으면 다시 segment 3번을 보낸다. 그런데 이때!!!! 속도 지연이 발생한다.

 

UDP보다 느린 이유 지연이 발생하는 메인 이유 : 순서대로 이므로 다음을 기다려야 한다.

Segment가 주어지면 수신측 TCP 버퍼에서 저장할 수 있는 공간:  WINDOW SIZE

ack는 window size를 포함한다.

 

3번을 보내야 하는데 이를 보내야할지 말아야 할지를 ack windowsize 를 보고 판단한다. 

전송을 할 경우에는 수신측의 window size 와  보내야 할 max segment size 를 비교한다.

만약에 그렇다면 보내고, 그렇지 않다면 Wait이 걸린다!!!

 

느린 이유는 서버가 느린 것일 수도 있지만 수신하는 과정이 느릴 수도 있다!

클라이언트는 TCP에 저장되어 있던 것을 메모리(file I/O buffer)로 빨리 전송해야 한다.

이걸 receive하는 속도, read 속도가 네트워크에서 수신하는 속도보다 무조건 빨라야 한다.

느리면 여유 공간이 없어 아예 전송이 안되기 때문이다 ...

 

그래서 개발자는 원인을 네트워크에서 찾는 것이 아니라 프로그램에서도 찾아야 한다. (데이터를 받는 쪽에서 전송 속도)

처리 지연에 문제가 발생하고 있을 수 있으므로

 

결론 : tcp ip 는 송신보다 수신쪽에 더 문제가 있을 수 있다.

 

 

출처 : 널널한 개발자 TV