[ 네트워크 이야기 #1 ] OSI 7 Layers(4-7), HTTP, TCP, UDP

안녕하세요. 이번 포스팅에서는 OSI 7 계층과 Application Layer부터 Transport Layer까지를 알아보는 포스팅을 진행하겠습니다.

 

먼저, 네트워크에 대한 큰 틀을 이해하기 위해 OSI(Open Systems Interconnection Reference Model) 7 계층에 대해 이해하고 계셔야 합니다.

 

OSI 7 Layers

 

 

1. OSI 모델(Open Systems interconnection Reference Model)은 국제 표준화 기구(ISO)에서 개발한 모델로, 컴퓨터 네트워크 프로토콜 디자인과 통신을 계층으로 나누어 설명한 것입니다.

 

2. 순서대로,

애플리케이션 계층, 표현 계층, 세션 계층, 전송 계층, 네트워크 계층, Data Link 계층, 물리적 계층 총 7개의 계층으로 네트워크 통신을 나누어 설명한 모델입니다.

 

3. 각 계층은 하위 계층의 기능만을 이용하고, 상위 계층에게 기능을 제공한다는 기준을 바탕으로 네트워크에서 통신이 일어나는 과정을 7단계로 나눈 것을 말합니다.

 

4. 송신 측에서 데이터를 encapsulation하고, 수신 측에서 decapsulation를 통해 데이터를 확인합니다.

 

5. 각 계층을 프로토콜 별로 나누었다고 볼 수도 있으며, 스택형으로 쌓아지고 recive할때 하나씩 decapsulation하기 때문에 프로토콜 스택으로 불리기도 합니다.

 

OSI 7 계층으로 분리했을 때의 장점

위 그림처럼 7계층으로 분리하게 되면 각 프로토콜을 독립적으로 이해할 수 있습니다. 또한 각 계층에 문제가 발생했을 때, 문제가 발생한 계층만 수정이 가능하게 됩니다.

 

7. Application Layer(HTTP, SMTP, FTP, DNS)

OSI 7계층의 최 상단 Layer입니다. 여기서는 저희가 흔히 사용하는 웹 프로토콜인 HTTP, 이메일 프로토콜인 SMTP, 파일 전송 프로토콜인 FTP, IP 주소를 찾기 위한 DNS 등이 해당됩니다. 즉 네트워크가 결국 Application과 Application과의 통신 과정이라면, 궁극적으로 전달해야 할 메시지가 생성되는 Layer입니다. 

 

5, 6. Session, Presentation Layer

Session Layer에서는 저희가 흔히 사용하는 Session의 개념과 유사합니다. 통신을 위한 논리적인 연결을 수행합니다.

Presentation Layer에서는 Application에서 활용된 다양한 코드 간의 번역을 맡아줍니다. 이를 함으로써, Application Layer의 부담을 덜어주게 됩니다. 또한 인코딩, 압축, 암호화와 같은 기능을 제공해줍니다.

 

4. Transport Layer (TCP, UDP)

End to End 통신의 최 하단의 Layer입니다. 사용되는 통신 프로토콜로는 TCP, UDP가 있으며 이 둘의 차이에 대해서는 후술하겠습니다.

 

 

여기까지의 흐름을 보면, Application Layer에서 전송하고자 하는 message를 TCP 혹은 UDP 소켓을 통해 목적지의 TCP 혹은 UDP 소켓으로 전송됩니다. 그러면 reciever는 해당 segment를 분리하여 message를 전달받게 됩니다.

 

 

HTTP란? 

HTTP는 HyperText Transfer Protocol의 약자입니다. 쉽게 생각하면 일종의 Text를 전달하는 프로토콜인데, (HyperText는 링크를 활용한 Text라고 보시면 됩니다) 인터넷에서 데이터를 주고받을 수 있게 설계된 규약이라고 할 수 있습니다. 

 

HTTP의 특징

1. HTTP 메시지는 Client와 Server로부터 해석됩니다.

2. TCP/IP를 사용하는 프로토콜입니다. 

3. Stateless 한 프로토콜입니다. Stateless란 연결 상태를 유지하지 않는 프로토콜이라는 의미입니다. 이를 보안하기 위해 Cookie와 Session과 같은 개념이 도입되었습니다.

 

HTTP Request 메서드

HTTP Request 메서드는 크게 다음 네 가지의 메서드가 존재합니다.

1. GET -> 어떠한 자료에 대한 조회를 요청합니다.

2. POST -> 어떠한 자료에 대한 저장을 요청합니다.

3. PUT -> 어떠한 자료에 대한 수정을 요청합니다.

4. DELETE -> 어떠한 자료에 대한 삭제를 요청합니다.

 

Patch(부분 수정 요청)와 같은 다른 메서드도 존재하는데, 큰 틀은 위 네가지 메서드를 주로 사용합니다.

* 추가 메서드에 대한 정보 https://developer.mozilla.org/ko/docs/Web/HTTP/Methods

HTTP 요청 메서드 - HTTP | MDN

 

HTTP Response

보통 HTTP response는 다음과 같은 상태 코드를 포함합니다.

• 1XX (조건부 응답) : 요청을 받았으며 작업을 계속함을 의미합니다.
• 2XX (성공) : 요청이 성공적으로 수행되었음을 의미합니다.
• 3XX (리다이렉션 완료)
• 4XX (요청 오류) : 클라이언트의 요청이 무언가 잘못되었음을 의미합니다.
• 5XX (서버 오류) : 서버가 요청에 대한 적절한 수행을 하지 못했음을 의미합니다.

 

HTTP의 단점

• HTTP는 평문 통신이기 때문에 도청이 가능합니다.
• 통신 상대를 확인하지 않기 때문에 위장이 가능합니다.
• 완전성을 증명할 수 없기 때문에 변조가 가능합니다.

 

즉 HTTP는 평문 통신이기 때문에 (별도의 암호화 과정을 거치지 않기 때문에) 보안성에 문제가 발생합니다.

 

또한, 통신 상대를 확인하지 않는다. 즉 IP/port에 아무나 요청을 보낼 수 있지만, 요청을 보낸 상대방에 대한 일종의 증명과정이 생략되어 있기 때문에 위장이 가능합니다.

 

마지막으로, HTTP 프로토콜의 response를 중간에 누군가 가로채서 변조한 다음 Client에게 돌려주게 되어도 원래의 데이터와 구분할 방법이 없어지게 됩니다.

 

이러한 문제를 해결하기 위해 나온 Protocol이 HTTPS입니다.

 

HTTPS란?

HTTPS란 위 HTTP의 문제점을 수정한, 즉 HTTP에 완전성, 암호화, 인증을 더한 프로토콜입니다.

 

이는 HTTP + SSL로 설명할 수 있습니다. 

 

즉 HTTP(Application Layer) -> TCP(Transport Layer)의 과정을

HTTP(Application Layer) -> SSL -> TCP(Transport Layer)의 과정으로 SSL을 추가하여 위의 기능들을 수행하게 됩니다.

 

물론 HTTPS로 진행하게 되면, 기존의 HTTP보다 느려지는 것 아닌가?라는 의문점과 함께 모든 요청에 대해 HTTPS로 사용해야 하나라는 궁금점이 생깁니다. 하지만 최근에는 하드웨어의 발달로 인해 HTTPS를 사용하더라도 속도 저하가 거의 일어나지 않으며, 새로운 표준인 HTTP 2.0을 함께 이용한다면 오히려 HTTPS가 HTTP보다 더 빠르게 동작한다고 합니다.

 

따라서 웹은 과거의 민감한 정보를 다룰 때만 HTTPS에 의한 암호화 통신을 사용하는 방식에서 현재 모든 웹 페이지에서 HTTPS를 적용하는 방향으로 현재 바뀌고 있습니다.

 

 

여기까지 Application Layer의 대표적인 프로토콜인 HTTP에 대해서 알아보았습니다. 

 

이번에는 Transport Layer의 프로토콜인 TCP와 UDP에 대해서 알아보도록 하겠습니다.

 

UDP란?

User Datagram Protocol의 약어로써, Transport Layer가 기본적으로 제공하는 최소한의 기능만을 제공한 통신 Protocol을 말합니다. Transport Layer가 기본적으로 제공하는 기능인 Multiplexing(여러 소켓으로부터 온 메시지를 전달하는 역할)/Demultiplexing (여러 소켓 중 정확하게 목적 Socket으로 보내는 역할)만을 수행합니다. 

 

UDP는 통신 제어(Congestion Control), 흐름 제어(Flow Control)를 제공하지 않으며 비 연결형 통신입니다. 비 연결형 통신이기 때문에, 신뢰성이 높지 않습니다. 

 

신뢰성이 높지 않다는 의미는 내가 현재 보내는 데이터가 확실하게 목적지에 에러 없이 도착한다는 확신이 부족하다는 의미입니다. 

 

하지만 여러 제어를 하지 않고, 연결하는 과정도 없기 때문에 굉장히 빠릅니다. 따라서 굳이 신뢰성이 보장되지 않아도 되며, 속도가 중요한 전화, Streaming Service나 DNS와 같은 곳에서 사용됩니다.

 

TCP란?

Transmission Control Protocol의 약어로써, 위의 UDP와 반대로, 연결형 통신을 수행하며 순차적으로 전송되는 Protocol입니다. 당연하게도, 신뢰성이 중요한 분야에 사용됩니다. 수신자와 송신자의 각각 Socket 간의 연결을 먼저 설정한 뒤, byte stream으로 전송이 진행됩니다. 신뢰성을 보장하기 위해 여러 제어를 제공하며, 여러 기능을 제공하기 때문에 Header의 크기가 UDP에 비해 크고, 다양한 필드가 존재합니다. 또한 point - to - point 통신이기 때문에 멀티캐스팅이나 브로드캐스팅을 제공하지 않습니다.

 

TCP Connection

TCP는 3-way handshake를 통해 연결을 만들고, 4-way handshake를 통해 연결을 해제합니다.

 

3-way handshake란 SYN -> SYN, ACK -> ACK를 통해 Client와 Server 간의 통신을 만드는 것을 말합니다.

4-way handshake란 FIN -> ACK, FIN -> ACK로 네 번의 과정을 통해 통신을 해제하는 것을 말합니다.

 

 

Flow Control, Congestion Control

TCP는 Flow Control(흐름 제어)와 Congestion Control(혼잡 제어)의 기능을 제공합니다. 흐름 제어는 reciever의 버퍼의 상태에 따라서 적절한 송신량을 유지하는 제어 기능을 말하며, 혼잡 제어는 네트워크의 상황에 알맞은 전송량을 정하는 것을 말합니다.

 

흐름 제어 기법으로는, Stop and Wait 방법과, Sliding Window 방법이 있습니다.

 

Stop and Wait 방법은 하나의 패킷을 전송하였을 때 그에 대한 ACK가 도착해야만 다음 패킷을 전송하는 전략을 말합니다.

Sliding Window 방법은 수신자로부터 받은 Window Size만큼의 패킷을 확인 없이 전달할 수 있게 하는 방법입니다. 이는 동적으로 flow control이 가능하게 만들어 줍니다.

 

혼잡 제어는 다음 세 가지를 통해 제공합니다.

 

1. Slow Start

2. Addictive increase

3. Multiplicative decrease

 

1. Slow Start는 초기 MSS(Maximum Segment Size)를 1로 설정한 뒤, exponential 하게 윈도우 사이즈를 증가하는 방법을 사용하는 것을 말합니다. 이는 설정된 Threshold까지 증가하게 됩니다.

 

2. Addictive increase는 앞서 말한 제곱수로 MSS를 증가하는 방법을 말합니다.

 

3. 2와 같이 증가하다가 임계값을 만나게 되면, 그 값을 반으로 줄이는 것을 의미합니다. 

 

오늘은 이렇게 OSI 7 계층 중 4~7 계층에 대해 간략히 알아보고, HTTP, TCP, UDP에 대해 정리하는 포스팅을 가져보았습니다.

 

*저의 글에 대한 피드백이나 지적은 언제나 환영합니다.