Application Layer: 두 판 사이의 차이
편집 요약 없음 |
|||
| (같은 사용자의 중간 판 4개는 보이지 않습니다) | |||
| 15번째 줄: | 15번째 줄: | ||
==Creating a Network application== | ==Creating a Network application== | ||
네트워크 애플리케이션 개발의 핵심은 서로 다른 end system에서 실행되며, 네트워크를 통해 communicate(통신)하는 프로그램을 작성하는 것이다. 예를 들어, web server software는 user device와 server라는 서로 다른 end system에서 실행되며, 네트워크를 통해서 상호간의 통신을 한다. 이때 중요한 점은 네트워크 애플리케이션이 네트워크를 이용할 때는 이미 만들어져 있는 core network의 infrastructure를 그래도 활용한다는 것이다. 이 때문에 소프트웨어를 작성할 때에는 네트워크의 core 부분에 대해 고려할 필요가 없으며, 마치 end system 간의 직접적인 연결이 이루어진 것처럼 | 네트워크 애플리케이션 개발의 핵심은 서로 다른 end system에서 실행되며, 네트워크를 통해 communicate(통신)하는 프로그램을 작성하는 것이다. 예를 들어, web server software는 user device와 server라는 서로 다른 end system에서 실행되며, 네트워크를 통해서 상호간의 통신을 한다. 이때 중요한 점은 네트워크 애플리케이션이 네트워크를 이용할 때는 이미 만들어져 있는 core network의 infrastructure를 그래도 활용한다는 것이다. 이 때문에 소프트웨어를 작성할 때에는 네트워크의 core 부분에 대해 고려할 필요가 없으며, '''마치 end system 간의 직접적인 연결이 이루어진 것처럼 고려'''하여 개발하면 된다는 것이다.<ref>역으로 core 부분 또한 application의 구동에 대해서 고려할 필요가 없다.</ref> 이렇게 application software 설계를 end system에 제한하면 해당 설계를 더욱 빠르게 하고, 배포 또한 더욱 빠르게 할 수 있다.[[파일:ClientServer.png|대체글=Client-Server Architecture|섬네일|263x263픽셀|Client-Server Architecture]] | ||
=== Client-server architecture === | |||
client-server 아키텍쳐는 서버(server)와 클라이언트(client)로 구성된다. | |||
* '''서버: 다른 host(클라이언트 등)들의 요청을 처리'''한다. | |||
** 항상 켜져있으므로, 클라이언트는 서버와 언제나 통신할 수 있다. | |||
client-server 아키텍쳐는 | ** '''고정되고 공개된 IP 주소'''를 가지고 있어서 이릍 통해 클라이언트이 서버와 통신할 수 있다. | ||
* | ** 또한 서버가 과부화가 될 경우에는 data center를 통해 서버를 확장할 수 있다. | ||
** 항상 켜져있으므로, | * '''클라이언트: 서버와 통신하고자 하는 각 유저의 device'''에 해당한다. | ||
** 고정되고 공개된 IP | |||
** 또한 | |||
* | |||
** 항상 네트워크와 연결되어 있지는 않으며, 간헐적으로 연결된다.<ref>핸드폰의 비행기 탑승 모드가 그 예시이다.</ref> | ** 항상 네트워크와 연결되어 있지는 않으며, 간헐적으로 연결된다.<ref>핸드폰의 비행기 탑승 모드가 그 예시이다.</ref> | ||
** 동적인 IP 주소를 가지고 | ** '''동적인 IP 주소를 가지고 있'''기 때문에, '''클라이언트 사이에서의 직접적인 연결은 이루어지지 않는다.'''<ref>노트북은 wifi에 따라 그 IP주소가 바뀐다.</ref> | ||
Client-server 아키텍쳐의 가장 큰 문제는 클라이언트 간의 통신에도 서버가 필요할 뿐만 아니라, 서버에 대한 의존도가 높아 만약의 경우에 대한 그 위험이 매우 크다는 것이다. 하지만 최근에는 서버의 성능이 비약적으로 상승함에 따라, 해당 아키텍쳐의 효율이 매우 높아졌다. | |||
[[파일:P2P.png|섬네일|263x263픽셀|P2P Architecture]] | [[파일:P2P.png|섬네일|263x263픽셀|P2P Architecture]] | ||
=== [[P2P architecture]] === | |||
고정되어 있는 | 고정되어 있는 서버가 존재하지 않는다. 그 대신에 애플리케이션은 간헐적으로 연결되는 '''호스트(host)간의 직접적인 통신을 이용'''한다. 이때 임의의 end system 사이의 직접적인 통신이 이루어지며, 이는 임의의 agent가 서버로서 기능을 할 수 있다는 것을 의미한다.<ref>하지만 여전히 각 peer들은 간헐적으로 네트워크와 연결되며, 유동적인 IP 주소를 가진다.</ref> 이때 각 peer는 다른 peer에게서 서비스를 요청하고, 다른 peer에게 서비스를 제공한다. 이러한 '''P2P 아키텍쳐의 가장 큰 특징 중 하나는 self scalability'''이다. 이는 새로운 peer가 다른 peer에게 서비스를 요구함에 따라 부하가 증가하더라도, 각각의 peer가 서비스 capacity를 증가시킨다는 것이다. 즉, 네트워크의 크기가 유동적으로 변화하며 상황에 맞추어 각 end system간의 통신을 제공한다. | ||
이러한 특징으로 인해 P2P 아키텍쳐는 비용 측면에서 효율적이다. 왜냐하면 client-server 아키텍쳐에 비해 infrastructure나 server bandwidth가 적게 필요하기 때문이다. 하지만, 매우 분산된 구조를 가지고 있기 때문에 신뢰성, 보안, 성능 면에서 client-server 아키텍쳐에 비해 약점을 가지고 있다. | 이러한 특징으로 인해 P2P 아키텍쳐는 비용 측면에서 효율적이다. 왜냐하면 client-server 아키텍쳐에 비해 infrastructure나 server bandwidth가 적게 필요하기 때문이다. 하지만, 매우 분산된 구조를 가지고 있기 때문에 신뢰성, 보안, 성능 면에서 client-server 아키텍쳐에 비해 약점을 가지고 있다. | ||
| 40번째 줄: | 37번째 줄: | ||
==Process communicating== | ==Process communicating== | ||
프로세스(Process)란 호스트 내에서 동작하는 프로그램<ref>그 자체로는 저장된 파일이므로 아무런 기능이 없다.</ref>을 의미한다. 같은 호스트 내에서 동작하고 있는 프로세스는 inter-process commnication을 통해서 서로 간의 상호작용을 한다.<ref>OS에 의해서 구현된다.</ref> | |||
하지만 end system들 또한 다수의 | 하지만 end system들 또한 다수의 프로세스를 가지고 있다. 이 때문에 서로 다른 호스트들 사이에서도 프로세스 사이의 통신이 이루어져야 한다. 이러한 통신은 각각의 프로세스들이 상대 end system에 네트워크를 통해서 메시지를 교환하여 이루어진다. | ||
===Client / Server process=== | ===Client / Server process=== | ||
네트워크 애플리케이션은 네트워크를 통해 서로 메시지를 주고받는 프로세스의 pair로 구성된다. 예를 들어 | 네트워크 애플리케이션은 네트워크를 통해 서로 메시지를 주고받는 프로세스의 pair로 구성된다. 예를 들어 '''웹 애플리케이션에서는 클라이언트 브라우저 프로세스가 웹 서버 프로세스와 메시지를 교환'''한다. 이때 '''초기 상태에서 통신을 시작하는 프로세스는 클라이언트 프로세스'''이다. 또한 통신을 시작하기 위해 '''클라이언트의 메시지를 기다리는 프로세스는 서버 프로세스'''에 해당한다. | ||
이때 P2P 아키텍쳐에서는 한 peer의 프로세스에서 다른 peer의 프로세스로 파일이 전송된다. 통신하는 프로세스들의 각 pair에 대해서는 두 프로세스 중 하나를 | 이때 P2P 아키텍쳐에서는 한 peer의 프로세스에서 다른 peer의 프로세스로 파일이 전송된다. 통신하는 프로세스들의 각 pair에 대해서는 두 프로세스 중 하나를 클라이언트로, 다른 하나를 서버로 구분한다. 예를 들어 '''P2P file sharing에서는 파일을 다운로드하는 peer가 클라이언트로, 파일을 업로드하는 peer가 서버로 구분'''된다. 하지만 P2P 아키텍쳐에서는 하나의 프로세스가 클라이언트이자 서버의 역할을 한다. 실제로 P2P file sharing에서는 하나의 프로세스가 파일을 업로드도, 다운로드도 할 수 있다. 그럼에도 두 프로세스 간의 통신을 고려할 때, 여전히 하나는 클라이언트, 다른 하나는 서버로 구분된다. | ||
===Socket=== | ===Socket=== | ||
대부분의 애플리케이션은 통신하는 프로세스들의 pair로 구성되며, 각 pair의 두 프로세스는 서로 | 대부분의 애플리케이션은 통신하는 프로세스들의 pair로 구성되며, 각 pair의 두 프로세스는 서로 메시지(message)를 주고받으며, 모든 메시지는 네트워크를 통해 전달된다. 이때 '''프로세스는 socket이라는 software interface를 통하여 메시지를 송수신'''한다. | ||
socket은 문과 같은 역할을 한다. 프로세스가 다른 | socket은 문과 같은 역할을 한다. 프로세스가 다른 호스트의 프로세스에 메시지를 보내고자 할 때, 해당 메시지는 문(socket)을 통해 네트워크로 전송된다. 전송된 메시지는 transport infrastructure를 통해 목적지로 설정된 호스트에 도달하면 메시지는 해당 호스트의 프로세스의 문(socket)을 통과하고, 최종적으로 수신된다. | ||
[[파일:IPandPort.png|섬네일|300x300픽셀|IP address and Port number to indentify process]] | [[파일:IPandPort.png|섬네일|300x300픽셀|IP address and Port number to indentify process]] | ||
===Addressing Processes=== | ===Addressing Processes=== | ||
메시지가 특정 프로세스로 잘 전달되어 수신되기 위해서는 수신하는 프로세스를 지정하는 identifier가 필요하다. 이때 두가지 정보가 필요한데, 하나는 호스트의 주소이고, 하나는 호스트 내에서 프로세스를 지정하는 식별자이다. | |||
이때 인터넷에서 '''호스트는 IP address로 식별'''된다. IP address는 호스트 device가 가지는 128 bits의 고유한 주소이다. 또한 해당 호스트 내에서 '''프로세스를 식별하는 데에는 port number'''가 사용된다. port number는 호스트의 프로세스에 지정되는 0~65635의 범위에 해당되는 indentifier이다. 이때 IP address와 port number는 pair로 사용되어 메시지가 의도된 프로세스에 잘 수신되도록 한다. 오른쪽의 그림은 IP address와 port number를 통해서 web 서버와 mail 서버로 올바르게 전달되는 메시지를 보여준다. 보통 web 서버와 mail 서버는 하나의 서버 안에 구축되어 있기 때문에, port number에 따라 그에 맞는 프로세스로 수신되는 것을 보여준다. | |||
{| class="wikitable" | |||
|+ | |||
!포트 종류 | |||
!포트 번호 범위 | |||
!설명 | |||
|- | |||
|Well-known port | |||
|0~1023 | |||
|시스템 사용 번호(슈퍼 유저 권한 필요), 사용 권장 X | |||
|- | |||
|Registered port | |||
|1024~49151 | |||
|특정 프로토콜이나 어플리케이션에서 사용하는 번호 | |||
|- | |||
|Dynamic port | |||
|49151-65535 | |||
|어플리케이션에서 사용하거나, 임시로 사용되는 번호 | |||
|} | |||
이때 port number는 프로세스에 따라 저장되므로, port number가 다른 프로세스의 port number와 겹치는 경우가 발생할 수 있다. 이러한 상황을 막기 위해서 특정한, 자주 사용되는 프로세스들은 port번호가 미리 지정되어 있다. | 이때 port number는 프로세스에 따라 저장되므로, port number가 다른 프로세스의 port number와 겹치는 경우가 발생할 수 있다. 이러한 상황을 막기 위해서 특정한, 자주 사용되는 프로세스들은 port번호가 미리 지정되어 있다. | ||
| 71번째 줄: | 83번째 줄: | ||
#* file 전송, web 문서 전송, e-mail과 같은 앱들은 조금의 data 손실이 치명적인 결과를 야기할 수 있기 때문에 100% reliable한 data transfer를 요구한다. | #* file 전송, web 문서 전송, e-mail과 같은 앱들은 조금의 data 손실이 치명적인 결과를 야기할 수 있기 때문에 100% reliable한 data transfer를 요구한다. | ||
#* audio/video, interactive game과 같은 애플리케이션은 약간의 data 손실에 대해서도 tolerate할 수 있기도 하다. | #* audio/video, interactive game과 같은 애플리케이션은 약간의 data 손실에 대해서도 tolerate할 수 있기도 하다. | ||
# timing: timing을 보장한다는 것은 주어진 시간 내에 송신한 data들이 목표로 삼는 | # timing: timing을 보장한다는 것은 주어진 시간 내에 송신한 data들이 목표로 삼는 호스트의 프로세스에 도달한다는 것을 의미한다. | ||
#* audio/vedio, interactive game과 같은 애플리케이션들은 정상적으로, effective하게 동작하기 위해 timing 보장을 요구한다. | #* audio/vedio, interactive game과 같은 애플리케이션들은 정상적으로, effective하게 동작하기 위해 timing 보장을 요구한다. | ||
#* 반면 file 전송, web 문서 전송, e-mail과 같이 timing의 지연에 대한 엄격한 제약이 없는 애플리케이션도 존재한다. | #* 반면 file 전송, web 문서 전송, e-mail과 같이 timing의 지연에 대한 엄격한 제약이 없는 애플리케이션도 존재한다. | ||
| 77번째 줄: | 89번째 줄: | ||
#* audio/vedio, interactive game과 같은 경우는 일정 수준의 throughput을 만족하지 않으면 이용하는데 장애가 생기는 애플리케이션이 있다. | #* audio/vedio, interactive game과 같은 경우는 일정 수준의 throughput을 만족하지 않으면 이용하는데 장애가 생기는 애플리케이션이 있다. | ||
#* 하지만 file 전송, web 문서 전송, e-mail, text messaging과 같이 throughput에 큰 구애를 받지 않는 애플리케이션도 존재한다. | #* 하지만 file 전송, web 문서 전송, e-mail, text messaging과 같이 throughput에 큰 구애를 받지 않는 애플리케이션도 존재한다. | ||
# security: transport protocol은 애플리케이션에 보안 서비스를 제공한다. 예를 들어, 송신 | # security: transport protocol은 애플리케이션에 보안 서비스를 제공한다. 예를 들어, 송신 호스트에서 transport protocol은 송신 프로세스가 전송하는 모든 data를 암호화할 수 있으며, 수신 호스트에서는 transport layer protocol이 data를 수신 프로세스에 전달하기 전에 이를 복호화할 수 있습니다. 이러한 service는 송수신 프로세스 간의 기밀성을 제공한다. | ||
==Transport Services Provided by the Internet== | ==Transport Services Provided by the Internet== | ||
| 83번째 줄: | 95번째 줄: | ||
===[[TCP]] service=== | ===[[TCP]] service=== | ||
[[TCP]]는 connection- | '''[[TCP]]는 connection-oriented'''하다. TCP에서 클라이언트와 서버 사이에 메시지가 송수신되기 전에 서로 transport layer control information을 교환하며 이루어지는 setup 절차를 handshaking이라고 한다. 이때 handshaking이 완료된 이후에 비로소 두 프로세스의 socket사이에 TCP 연결이 존재한다고 한다. | ||
또한 TCP는 data의 reliable transport를 보장한다. 따라서 TCP로 통신하는 프로세스는 전송되는 모든 데이터를 오류없이 순서대로 전달받을 수 있다. 그리고 congestion control 메커니즘을 가지고 있는데, 이는 전반적인 인터넷 환경이 너무 혼잡해지지 않도록 하는 역할을 한다. 또한 flow control 기능을 제공하여 sender가 receiver를 압도하지 않도록 한다. | 또한 TCP는 data의 reliable transport를 보장한다. 따라서 TCP로 통신하는 프로세스는 전송되는 모든 데이터를 오류없이 순서대로 전달받을 수 있다. 그리고 congestion control 메커니즘을 가지고 있는데, 이는 전반적인 인터넷 환경이 너무 혼잡해지지 않도록 하는 역할을 한다. 또한 flow control 기능을 제공하여 sender가 receiver를 압도하지 않도록 한다. | ||
하지만 timing, minimum throuput 보장, security | 하지만 '''timing, minimum throuput 보장, security 서비스는 제공하지 않는다.''' | ||
즉, 전반적으로 data integrity가 중요한 프로세스간의 통신에 대해 사용된다. | 즉, 전반적으로 data integrity가 중요한 프로세스간의 통신에 대해 사용된다. | ||
===[[UDP]] service=== | ===[[UDP]] service=== | ||
[[UDP]]는 간단하고 가벼운 transport | '''[[UDP]]는 간단하고 가벼운 transport protocol'''로, 최소한의 서비스를 제공한다. UDP는 connection-oriented하지 않기 때문에, 두 프로세스가 통신을 시작하기 전 핸드셰이킹이 없다. 이러한 특성으로 인해 UDP는 unreliable data transport service를 제공한다. 따라서 timing, data integrity, minimum throuput guarantee, security, connection setup, flow control, congestion control 등의 많은 서비스를 제공하지 않는다. | ||
하지만 단순한 만큼 송신자 측에는 어떠한 제약 조건도 주어지지 않아 주로 timing이 중요한 프로세스간의 통신에 대해 사용된다. | |||
하지만 단순한 만큼 | |||
==HTTP and Web== | ==HTTP and Web== | ||
| 116번째 줄: | 126번째 줄: | ||
==[[Video streaming and content distribution networks]]== | ==[[Video streaming and content distribution networks]]== | ||
자세한 내용은 [[Video streaming and content distribution networks]] 문서를 참조하십시오. | 자세한 내용은 [[Video streaming and content distribution networks]] 문서를 참조하십시오. | ||
==[[Socket programming]]== | |||
자세한 내용은 [[Socket programming]] 문서를 참조하십시오. | |||
==각주== | ==각주== | ||
[[분류:컴퓨터 네트워크]] | [[분류:컴퓨터 네트워크]] | ||
2025년 4월 29일 (화) 06:56 기준 최신판
상위 문서: 컴퓨터 네트워크
개요
network application(네트워크 애플리케이션)은 컴퓨터 네트워크의 존재 이유이다. 애플리케이션이 없었다면, 이를 지원하기 위한 네트워크 infrastructure와 protocol이 필요하지 않을 것이다. 이러한 애플리케이션들은 인터넷의 성공을 이끄는 원동력이며, 이를 통해 인터넷은 가정, 학교, 정부, 기업 등에 이미 필수적인 부분이 되었다.
이러한 네트워크 애플리케이션은 시대에 따라 순차적으로 개발되었다. 1970~1980년대에는 이메일과 같은 text 기반의 애플리케이션이 주가 되었다. 이후 1990년대 중반에 등장한 world wide web은 여러 웹 서비스 등을 제공하며 혁명적인 변화를 만들어내었다. 이후로도 remote login, P2P file 공유, 온라인 게임등 여러 application이 개발되었고, 그 외에도 voice over IP[1], streaming stored service[2], SNS 등의 여러 애플리케이션이 등장하며 인터넷의 발전을 가속화했다.
또한 Application Layer protocol은 protocol로 기능하기 위해 다음에 대해 정의하여야 한다.
- types of messages exchanged: 교환되는 메시지의 type을 정의한다.[3]
- message syntax: message에 어떤 field를 포함할지, 해당 field 들이 어떻게 구분될지를 정의한다.
- message semantics: message 내의 각 field에 대해 어떠한 정보를 담을지를 정의한다.[4]
- rule: 프로세스가 message를 언제 어떻게 송신하고 응답할지를 정의한다.
이렇게 정의된 protocol은 open protocol 혹은 proprietary protocol로 구분된다. open protocol은 RFC 문서에 규정되어, 누구에게나 무료로 공개되어 있다. 예를 들면 HTTP, SMTP가 있다. Proprietary protocol은 해당 protocol에 대한 특허권이 존재해 그 소유주에게 로열티를 지급하고 사용해야 하는 protocol을 의미한다. 예를 들면 VoIP가 이에 해당한다.
Creating a Network application
네트워크 애플리케이션 개발의 핵심은 서로 다른 end system에서 실행되며, 네트워크를 통해 communicate(통신)하는 프로그램을 작성하는 것이다. 예를 들어, web server software는 user device와 server라는 서로 다른 end system에서 실행되며, 네트워크를 통해서 상호간의 통신을 한다. 이때 중요한 점은 네트워크 애플리케이션이 네트워크를 이용할 때는 이미 만들어져 있는 core network의 infrastructure를 그래도 활용한다는 것이다. 이 때문에 소프트웨어를 작성할 때에는 네트워크의 core 부분에 대해 고려할 필요가 없으며, 마치 end system 간의 직접적인 연결이 이루어진 것처럼 고려하여 개발하면 된다는 것이다.[5] 이렇게 application software 설계를 end system에 제한하면 해당 설계를 더욱 빠르게 하고, 배포 또한 더욱 빠르게 할 수 있다.
Client-server architecture
client-server 아키텍쳐는 서버(server)와 클라이언트(client)로 구성된다.
- 서버: 다른 host(클라이언트 등)들의 요청을 처리한다.
- 항상 켜져있으므로, 클라이언트는 서버와 언제나 통신할 수 있다.
- 고정되고 공개된 IP 주소를 가지고 있어서 이릍 통해 클라이언트이 서버와 통신할 수 있다.
- 또한 서버가 과부화가 될 경우에는 data center를 통해 서버를 확장할 수 있다.
- 클라이언트: 서버와 통신하고자 하는 각 유저의 device에 해당한다.
Client-server 아키텍쳐의 가장 큰 문제는 클라이언트 간의 통신에도 서버가 필요할 뿐만 아니라, 서버에 대한 의존도가 높아 만약의 경우에 대한 그 위험이 매우 크다는 것이다. 하지만 최근에는 서버의 성능이 비약적으로 상승함에 따라, 해당 아키텍쳐의 효율이 매우 높아졌다.
P2P architecture
고정되어 있는 서버가 존재하지 않는다. 그 대신에 애플리케이션은 간헐적으로 연결되는 호스트(host)간의 직접적인 통신을 이용한다. 이때 임의의 end system 사이의 직접적인 통신이 이루어지며, 이는 임의의 agent가 서버로서 기능을 할 수 있다는 것을 의미한다.[8] 이때 각 peer는 다른 peer에게서 서비스를 요청하고, 다른 peer에게 서비스를 제공한다. 이러한 P2P 아키텍쳐의 가장 큰 특징 중 하나는 self scalability이다. 이는 새로운 peer가 다른 peer에게 서비스를 요구함에 따라 부하가 증가하더라도, 각각의 peer가 서비스 capacity를 증가시킨다는 것이다. 즉, 네트워크의 크기가 유동적으로 변화하며 상황에 맞추어 각 end system간의 통신을 제공한다.
이러한 특징으로 인해 P2P 아키텍쳐는 비용 측면에서 효율적이다. 왜냐하면 client-server 아키텍쳐에 비해 infrastructure나 server bandwidth가 적게 필요하기 때문이다. 하지만, 매우 분산된 구조를 가지고 있기 때문에 신뢰성, 보안, 성능 면에서 client-server 아키텍쳐에 비해 약점을 가지고 있다.
자세한 내용은 P2P architecture 문서를 참조하십시오.
Process communicating
프로세스(Process)란 호스트 내에서 동작하는 프로그램[9]을 의미한다. 같은 호스트 내에서 동작하고 있는 프로세스는 inter-process commnication을 통해서 서로 간의 상호작용을 한다.[10]
하지만 end system들 또한 다수의 프로세스를 가지고 있다. 이 때문에 서로 다른 호스트들 사이에서도 프로세스 사이의 통신이 이루어져야 한다. 이러한 통신은 각각의 프로세스들이 상대 end system에 네트워크를 통해서 메시지를 교환하여 이루어진다.
Client / Server process
네트워크 애플리케이션은 네트워크를 통해 서로 메시지를 주고받는 프로세스의 pair로 구성된다. 예를 들어 웹 애플리케이션에서는 클라이언트 브라우저 프로세스가 웹 서버 프로세스와 메시지를 교환한다. 이때 초기 상태에서 통신을 시작하는 프로세스는 클라이언트 프로세스이다. 또한 통신을 시작하기 위해 클라이언트의 메시지를 기다리는 프로세스는 서버 프로세스에 해당한다.
이때 P2P 아키텍쳐에서는 한 peer의 프로세스에서 다른 peer의 프로세스로 파일이 전송된다. 통신하는 프로세스들의 각 pair에 대해서는 두 프로세스 중 하나를 클라이언트로, 다른 하나를 서버로 구분한다. 예를 들어 P2P file sharing에서는 파일을 다운로드하는 peer가 클라이언트로, 파일을 업로드하는 peer가 서버로 구분된다. 하지만 P2P 아키텍쳐에서는 하나의 프로세스가 클라이언트이자 서버의 역할을 한다. 실제로 P2P file sharing에서는 하나의 프로세스가 파일을 업로드도, 다운로드도 할 수 있다. 그럼에도 두 프로세스 간의 통신을 고려할 때, 여전히 하나는 클라이언트, 다른 하나는 서버로 구분된다.
Socket
대부분의 애플리케이션은 통신하는 프로세스들의 pair로 구성되며, 각 pair의 두 프로세스는 서로 메시지(message)를 주고받으며, 모든 메시지는 네트워크를 통해 전달된다. 이때 프로세스는 socket이라는 software interface를 통하여 메시지를 송수신한다.
socket은 문과 같은 역할을 한다. 프로세스가 다른 호스트의 프로세스에 메시지를 보내고자 할 때, 해당 메시지는 문(socket)을 통해 네트워크로 전송된다. 전송된 메시지는 transport infrastructure를 통해 목적지로 설정된 호스트에 도달하면 메시지는 해당 호스트의 프로세스의 문(socket)을 통과하고, 최종적으로 수신된다.
Addressing Processes
메시지가 특정 프로세스로 잘 전달되어 수신되기 위해서는 수신하는 프로세스를 지정하는 identifier가 필요하다. 이때 두가지 정보가 필요한데, 하나는 호스트의 주소이고, 하나는 호스트 내에서 프로세스를 지정하는 식별자이다.
이때 인터넷에서 호스트는 IP address로 식별된다. IP address는 호스트 device가 가지는 128 bits의 고유한 주소이다. 또한 해당 호스트 내에서 프로세스를 식별하는 데에는 port number가 사용된다. port number는 호스트의 프로세스에 지정되는 0~65635의 범위에 해당되는 indentifier이다. 이때 IP address와 port number는 pair로 사용되어 메시지가 의도된 프로세스에 잘 수신되도록 한다. 오른쪽의 그림은 IP address와 port number를 통해서 web 서버와 mail 서버로 올바르게 전달되는 메시지를 보여준다. 보통 web 서버와 mail 서버는 하나의 서버 안에 구축되어 있기 때문에, port number에 따라 그에 맞는 프로세스로 수신되는 것을 보여준다.
| 포트 종류 | 포트 번호 범위 | 설명 |
|---|---|---|
| Well-known port | 0~1023 | 시스템 사용 번호(슈퍼 유저 권한 필요), 사용 권장 X |
| Registered port | 1024~49151 | 특정 프로토콜이나 어플리케이션에서 사용하는 번호 |
| Dynamic port | 49151-65535 | 어플리케이션에서 사용하거나, 임시로 사용되는 번호 |
이때 port number는 프로세스에 따라 저장되므로, port number가 다른 프로세스의 port number와 겹치는 경우가 발생할 수 있다. 이러한 상황을 막기 위해서 특정한, 자주 사용되는 프로세스들은 port번호가 미리 지정되어 있다.
Transport Services Available to Applications
Transport Layer에는 다수의 transport protocol이 존재해 애플리케이션을 개발할 때 사용가능한 transport protocol 중 하나를 선택해야 한다. 이때 transport protocol은 애플리케이션에 제공하는 service에 대해 강점과 단점이 같이 존재하기 때문에, 애플리케이션의 요구 사항에 가장 적합한 service를 제공하는 프로토콜을 선택해야 한다. 이때 transport protocol이 애플리케이션에 제공하는 service는 대표적으로 다음 네가지가 있다.
- data integrity: 패킷은 네트워크 전송과정에서 손실될 수 있다. 예를 들어, 패킷이 라우터의 queue를 초과하여 전송되어 packet drop이 발생하거나, 호스트나 라우터에서 일부 bit가 손상되어 drop될 수 있다.
- file 전송, web 문서 전송, e-mail과 같은 앱들은 조금의 data 손실이 치명적인 결과를 야기할 수 있기 때문에 100% reliable한 data transfer를 요구한다.
- audio/video, interactive game과 같은 애플리케이션은 약간의 data 손실에 대해서도 tolerate할 수 있기도 하다.
- timing: timing을 보장한다는 것은 주어진 시간 내에 송신한 data들이 목표로 삼는 호스트의 프로세스에 도달한다는 것을 의미한다.
- audio/vedio, interactive game과 같은 애플리케이션들은 정상적으로, effective하게 동작하기 위해 timing 보장을 요구한다.
- 반면 file 전송, web 문서 전송, e-mail과 같이 timing의 지연에 대한 엄격한 제약이 없는 애플리케이션도 존재한다.
- throughput: 단위 시간 동안 네트워크를 통해 sender와 receiver 사이에서 전달된 데이터의 양을 의미한다.
- audio/vedio, interactive game과 같은 경우는 일정 수준의 throughput을 만족하지 않으면 이용하는데 장애가 생기는 애플리케이션이 있다.
- 하지만 file 전송, web 문서 전송, e-mail, text messaging과 같이 throughput에 큰 구애를 받지 않는 애플리케이션도 존재한다.
- security: transport protocol은 애플리케이션에 보안 서비스를 제공한다. 예를 들어, 송신 호스트에서 transport protocol은 송신 프로세스가 전송하는 모든 data를 암호화할 수 있으며, 수신 호스트에서는 transport layer protocol이 data를 수신 프로세스에 전달하기 전에 이를 복호화할 수 있습니다. 이러한 service는 송수신 프로세스 간의 기밀성을 제공한다.
Transport Services Provided by the Internet
TCP service
TCP는 connection-oriented하다. TCP에서 클라이언트와 서버 사이에 메시지가 송수신되기 전에 서로 transport layer control information을 교환하며 이루어지는 setup 절차를 handshaking이라고 한다. 이때 handshaking이 완료된 이후에 비로소 두 프로세스의 socket사이에 TCP 연결이 존재한다고 한다.
또한 TCP는 data의 reliable transport를 보장한다. 따라서 TCP로 통신하는 프로세스는 전송되는 모든 데이터를 오류없이 순서대로 전달받을 수 있다. 그리고 congestion control 메커니즘을 가지고 있는데, 이는 전반적인 인터넷 환경이 너무 혼잡해지지 않도록 하는 역할을 한다. 또한 flow control 기능을 제공하여 sender가 receiver를 압도하지 않도록 한다.
하지만 timing, minimum throuput 보장, security 서비스는 제공하지 않는다.
즉, 전반적으로 data integrity가 중요한 프로세스간의 통신에 대해 사용된다.
UDP service
UDP는 간단하고 가벼운 transport protocol로, 최소한의 서비스를 제공한다. UDP는 connection-oriented하지 않기 때문에, 두 프로세스가 통신을 시작하기 전 핸드셰이킹이 없다. 이러한 특성으로 인해 UDP는 unreliable data transport service를 제공한다. 따라서 timing, data integrity, minimum throuput guarantee, security, connection setup, flow control, congestion control 등의 많은 서비스를 제공하지 않는다.
하지만 단순한 만큼 송신자 측에는 어떠한 제약 조건도 주어지지 않아 주로 timing이 중요한 프로세스간의 통신에 대해 사용된다.
HTTP and Web
HTTP
자세한 내용은 HTTP 문서를 참조하십시오.
Cookie
자세한 내용은 Cookie 문서를 참조하십시오.
Web Cache
자세한 내용은 Web Cache 문서를 참조하십시오.
Eletronic Mail
자세한 내용은 Eletronic Mail 문서를 참조하십시오.
DNS
자세한 내용은 DNS 문서를 참조하십시오.
Video streaming and content distribution networks
자세한 내용은 Video streaming and content distribution networks 문서를 참조하십시오.
Socket programming
자세한 내용은 Socket programming 문서를 참조하십시오.
각주
- ↑ 해당 기능을 구현하는 protocol은 특허가 등록되어 있어서 사용하기 위해서는 사용료를 내야한다.
- ↑ YouTube, Netflix등...
- ↑ 예를 들어 request와 response를 정의하는 것이 있다.
- ↑ 각 field에 담긴 데이터의 의미와 그 해석을 정의한다.
- ↑ 역으로 core 부분 또한 application의 구동에 대해서 고려할 필요가 없다.
- ↑ 핸드폰의 비행기 탑승 모드가 그 예시이다.
- ↑ 노트북은 wifi에 따라 그 IP주소가 바뀐다.
- ↑ 하지만 여전히 각 peer들은 간헐적으로 네트워크와 연결되며, 유동적인 IP 주소를 가진다.
- ↑ 그 자체로는 저장된 파일이므로 아무런 기능이 없다.
- ↑ OS에 의해서 구현된다.
