[Network] Port, Socket and Connection
"Port, Socket and Connection"
[Port]
· Process와 연결된 Data Path 또는 Data Channel (Port Name을 통해 식별)
* 0~1023 : Well-Known Ports, System Ports - Ex. HTTP(80), HTTPS(443), DNS(53)
* 49152~65535 : Dynamic Ports(등록되지 않은 번호, 임시 또는 자동 할당될 때 사용)
[Process 간의 통신]
Internet Protocol
· 데이터를 목적하는 Host까지 Routing하는 역할 = 최적의 경로로 전송하는 역할
· Unreliable(Data Loss, Out-of-Order)
TCP(Transmission Control Protocol)
· Process 간의 통신에서 데이터를 안정적(Reliable)으로 주고 받을 수 있는 Protocol
Connection in TCP
· Process간의 안정적이고 논리적인 통신 통로
· Connection-Oriented(연결 기반) : Connection Open(3-Way) → 데이터 주고 받기 → Connection Close(4-Way)
Socket in TCP
· Port(Number) : 16-bit로 이루어진 숫자 (0~65535) → Port Number만으로는 Unique하게 식별 불가
· Internet Address(IP Address)로 각 Host를 Unique하게 식별 가능 → Internet Address(IP Address) + Port Number = Socket
∴ Socket = 인터넷 상에 존재하는 각 Port를 Unique하게 식별하기 위한 주소
→ 즉, TCP 표준 관점에서 각 Socket은 인터넷 상에서 Unique
TCP Connection & Socket
· 각 Connection을 Unique하게 식별할 수 있어야 함 → 한 쌍의 Socket은 Connection을 Unique하게 식별 가능
· TCP Connection = [Src Socket, Dest Socket] = [Src Internet Address, Src Port, Dest Internet Address, Dest Port]
(Src = Source, Dest = Destination)
· 하나의 Socket은 동시에 여러 Connection에서 사용 가능
UDP(User Datagram Protocol)
· Connectionless : 연결을 맺지 않고 바로 데이터를 주고 받음
· Unreliable : Internet Protocol을 거의 그대로 사용
· UDP 표준(RFC 768)을 보면 Socket 단어 등장 X (이후에 자연스럽게 UDP에도 Socket 개념을 사용하기 시작)
· UDP까지 확장되면서 [Protocol, IP Address, Port Number]로 Unique하게 Socket 식별 (Protocol = UDP/TCP)
→ 3개의 값 중 최소 하나가 달라야 Unique해져 식별 가능
[Socket]
· Application이 System의 기능을 함부로 사용 불가
→ 대신 System은 Application이 네트워크 기능을 사용할 수 있도록 Programming Interface(= Socket)를 제공
∴ Application은 Socket을 통해 데이터를 주고 받음
· 개발자는 Socket Programming을 통해 네트워크 상의 다른 Process와 데이터를 주고 받을 수 있도록 구현 가능
· 대부분의 System은 Socket 형태로 네트워크 기능 제공
· 보통 Socket을 직접 조작해서 통신 기능을 구현할 일은 적음
→ Application Layer의 Protocol은 보통 Library 또는 Module 형태로 해당 기능이 제공되는데, 이때 내부를 열어보면 Socket을 활용해서 Protocol을 구현했음을 알 수 있음
[Protocol 표준 vs 실제 동작/구현]
Q) Protocol 표준에서 정의한 것처럼 Socket은 [Protocol, IP Address, Port Number]로 Unique하게 식별 되는가?
A) TCP = 불가 / UDP = 가능
· TCP 표준 - TCP Socket은 [(Dest)IP Address, (Dest)Port]가 Unique
· 실제 구현 - TCP Socket은 [(Dest)IP Address, (Dest)Port]만으로는 Unique하게 식별 불가(Src와 Dest 모두 비교해야 Unique 함)
TCP Socket 동작 방식
· Listening Socket : Connection 요청을 기다리는 Socket
· Connection 전 : Listening Socket의 [IP, Port]로 Socket 식별
· Connection 후 : [Src IP, Src Port, Dest IP, Dest Port]로 Socket 식별
Ex. 1bit syn 플래그 값이 1 → Listening Socket으로 전송 / 이미 연결된 Connection → [Src IP Address, Dest IP Address]로 식별
UDP Socket 동작 방식
· UDP Socket에서 데이터를 보낼 때 어느 UDP Socket으로 보낼지 지정 가능
· UDP Socket에서 데이터를 읽을 때 어느 UDP Socket으로부터 왔는지 알 수 있음
[데이터 전송]
· Payload : Protocol을 통해 송/수신되는 실제 데이터 → 상대적
· Data(or Message) : Application Layer에서 송/수신되는 데이터
→ Payload + Header (Payload = Data)
· TCP Segment/UDP Datagram : Transport Layer에서 송/수신되는 데이터
→ Payload + Header (Payload = Data + Application Layer의 Header)
→ Transport Layer의 Header = Src Port + Dest Port
· IP Datagram(or IP Packet) : Internet Layer에서 송/수신되는 데이터
→ Payload + Header (Payload = Data + Application Layer & Transport Layer의 Header)
→ Internet Layer의 Header = Src IP Address + Dest IP Address
→ TCP/UDP 정보도 Internet Layer의 Header에 저장
** IP Packet이 아닌 그냥 Packet은 인터넷을 통해 송/수신되는 데이터의 단위 → Layer 구분 없이 범용적으로 사용될 때가 많음
** Datagram : UDP Datagram인지 IP Datagram인지 구분 주의
· Frame : Link Layer에서 송/수신되는 데이터
→ Payload + Header + Trailer (Payload = Data + Application Layer & Transport Layer & Internet Layer의 Header)
· Demultiplexing : Internet Layer로부터 받은 Segment/Datagram에 있는 Payload를 적절한 Socket으로 전달하는 것
· Multiplexing : 여러 Socket들로부터 데이터를 수집해서 각각 Segment/Datagram으로 만든 후 Internet Layer로 내려보내는 것
Byte-Stream Protocol (TCP)
· Byte-Stream Protocol = Byte-Oriented Protocol = Stream-Oriented Protocol
· 사용하는 쪽에서 전송한 메세지를 구분 X
· 데이터 전송을 Byte들의 흐름 관점으로만 접근
· 메세지 단위로 다시 구분하는 책임은 Byte-Stream Protocol이 아닌 해당 Protocol을 사용하는 쪽에 존재
· TCP는 Reliable 데이터 전송을 실현하는 것이 목적
∴ Application에서 보낸 메세지와는 독립적으로, 특정 크기로 구분되는 별도의 전송 단위(TCP Segment)를 통해 데이터를 전송
** TCP Segment = TCP Header + Data / 특정 크기 = MSS(Maximum Segment Size)
(MSS를 초과한 데이터 전송 시 TCP가 알아서 MSS에 맞는 TCP Segment들로 나눠서 전송)
Ex. send("Hello, "), send("this is "), send("amazing!") ▶ read(…) → Hello, this is amazing!
Message-Oriented Protocol (UDP)
· 보낸 메세지 단위 그대로 받을 수 있게 해주는 Protocol
· 메세지 간의 경계를 구분 가능
· 한 번에 전송 가능한 메세지의 최대 크기가 존재
(최대 크기를 초과한 데이터 전송 시 Error 발생 → Error를 어떻게 처리할지는 개발자 또는 Application-Layer Protocol이 구현)
Ex. sendto("This "), sendto("is "), sendto("UDP!") ▶ recvfrom(...) → This , recvfrom(...) → is , recvfrom(...) → UDP!
Thinking
Q) Byte-Stream Protocol은 Reliable한가?
A) Reliable한지 여부와 독립적인 개념
· Byte-Stream Protocol이 Reliable → Reliable Byte-Stream Protocol → TCP
· Byte-Stream Protocol이 Unreliable → Unreliable Byte-Stream Protocol
· Message-Oriented Protocol이 Reliable → Reliable Message-Oriented Protocol
· Message-Oriented Protocol이 Unreliable → Unreliable Message-Oriented Protocol → UDP
Q) Byte-Stream Protocol을 사용하는 쪽에서 메세지를 구분하는 방법은 어떤 것들이 있나?
A) 여러 방법 존재. 그 중 몇 가지만 간단히 소개
· 메세지 사이즈를 고정
· 메세지의 사이즈를 먼저 보낸 후, 메세지를 보냄
· 메세지 사이에 구분자를 넣어서 전송
Q) TCP가 Byte-Stream Protocol이라면 TCP 위에서 동작하는 HTTP는 자체적으로 HTTP Message의 경계를 구분하는 방법을 가지고 있다는 말인가?
A) 그렇다. HTTP 버전에 따라 달라지는 부분 존재
댓글
댓글 쓰기