널리 사용되는 네트워크 프로토콜

Ahra YiAhra Yi
11 min read

원문: Subham Datta, "Popular Network Protocols"

1. 개요

이 튜토리얼에서는 가장 널리 사용되고 인기 있는 네트워크 프로토콜들을 소개합니다.

2. 네트워크 프로토콜 소개

의사소통과 정보 교환은 현대 사회에서 가장 중요하고 강력한 역량입니다. 컴퓨터 네트워킹이란 여러 대의 컴퓨터와 장치를 케이블이나 위성을 통해 서로 연결하여, 거리와 상관없이 정보·자원·데이터베이스 등을 공유할 수 있게 하는 것을 말합니다.

네트워크 내에서 효율적이고 안전한 통신을 보장하기 위해 다양한 프로토콜들이 설계되었습니다. 프로토콜이란 네트워크에서 통신이 어떻게 이루어지는지를 정의하는 규칙들의 집합입니다.

본질적으로 프로토콜은 연결된 장치들이 각각 내부 처리 방식이나 구조, 설계가 다르더라도 서로 통신할 수 있게 해주는 것입니다. 우리는 다양한 네트워크 프로토콜을 활용해 전 세계 사람들과 쉽게 소통할 수 있으며 이러한 프로토콜은 현대 디지털 통신에서 핵심적인 역할을 수행합니다.

3. 이더넷(Ethernet)

이더넷은 근거리 통신망(LAN)을 위해 만들어진 프로토콜입니다. 1983년에 처음으로 IEEE 802.3 표준으로 제정되었으며 굵은 동축 케이블인 10BASE-5와 함께 사용되었습니다.

이더넷 802.3 프로토콜은 유선 네트워크 모델에서의 물리 계층뿐만 아니라 데이터 링크 계층매체 접근 제어(MAC) 하위 계층도 정의합니다.

IEEE 802.3 프로토콜에는 다양한 버전이 존재합니다. 예를 들어 802.3a, 802.3i, 802.3j 등이 있습니다. 각 버전은 각기 다른 종류의 케이블 환경에서 작동하도록 설계되었습니다.

또 하나 널리 사용되는 프로토콜로는 IEEE 802.11이 있습니다. 이는 무선랜(WLAN)을 구현하기 위한 물리 계층 및 MAC 프로토콜을 정의합니다. IEEE 802.11은 무선 컴퓨터 네트워킹 표준으로 이를 통해 노트북과 스마트폰이 케이블 없이 통신할 수 있습니다.

다음은 IEEE 802.3과 IEEE 802.11 프로토콜의 프레임 형식입니다.

이더넷 802.3 프레임과 802.11 프레임의 구조를 비교한 것 그림입니다. 802.3 프레임은 왼쪽부터 순서대로 Preamble(7바이트), Start of Frame(SOF)(1바이트), Destination Address(6바이트), Source Address(6바이트), Data + Padding(46에서 1500바이트), Frame Check Sequence(FCS)(4바이트)로 구성되어 있습니다. 802.11 프레임은 왼쪽부터 Frame Control(2바이트), Duration/Connection ID(2바이트), 세 개의 Address 필드(각 6바이트), Sequence Control(2바이트), 추가 Address 필드(6바이트), Frame Body(0에서 2312바이트), Frame Check Sequence(FCS)(4바이트)로 구성되어 있으며, 이미지 하단에는 FC, D/I, SC, FCS 약어에 대한 설명이 포함되어 있습니다.

802.3과 802.11의 주요 차이점은 프레임 크기, 필드 구성, 전송 가능한 데이터 크기에 있습니다. IEEE 802.11 프로토콜은 802.3보다 주소 필드가 두 개 더 많고 프레임 본문 크기도 더 큽니다(802.3은 최대 1500바이트, 802.11은 최대 2312바이트).

4. 인터넷 프로토콜 (IP)

인터넷 프로토콜(Internet Protocol)은 1974년 IEEE에 의해 표준화되었으며 디지털 네트워크에서 데이터 패킷의 주소 지정과 단편화를 담당하는 프로토콜입니다. 주요 목적은 출발지에서 목적지까지 패킷이 성공적으로 전달되도록 보장하는 것입니다. 이를 위해 IP는 IP 데이터그램이라 불리는 데이터 패킷 형식과 그 구조를 정의합니다.

IP의 첫 번째 주요 버전은 IPv4이며 1982년 SATNET에서 처음 사용되었습니다. IPv4는 32비트 주소 공간을 사용합니다. 가장 최신 버전인 IPv6는 128비트 주소 공간을 활용하여 고유한 TCP/IP 주소를 생성할 수 있도록 설계되었습니다.

다음은 IPv4와 IPv6의 헤더 형식입니다.

IPV4 headerIPv4 헤더 구조를 나타낸 이미지입니다. 상단 비트 0~31 구간에는 Version(4비트), Header Length(4비트), Type of Service(ToS)(8비트), Total Packet Length(16비트) 필드가 포함되어 있습니다. 다음 줄에는 Identification(16비트), Flag(3비트), Fragment Offset(13비트) 필드가 이어지며, 그 아래에는 Time to Live(TTL)(8비트), Protocol(8비트), Checksum Header(16비트) 필드가 배치되어 있습니다. 이후에는 Source Address(32비트), Destination Address(32비트) 필드가 순서대로 위치하며, 마지막 줄에는 선택적으로 사용되는 Options 필드가 포함되어 있습니다.

다음 이미지는 IPv6 헤더 구조를 보여주는 것입니다. 첫 번째 줄에는 Version(4비트), Traffic Class(8비트), Flux Identification(20비트) 필드가 배치되어 있으며, 다음 줄에는 Data Length(16비트), Next Header(8비트), Hop-Limit(8비트) 필드가 나열되어 있습니다. 그 아래에는 Source Address(128비트), Destination Address(128비트) 필드가 각각 한 줄씩 차지하며, 전체 IPv6 헤더는 총 320비트로 구성되어 있습니다.

IPv4와 IPv6의 가장 큰 차이점은 주소 공간의 크기입니다. 또한 두 버전의 차이는 각 헤더 구조에서도 드러납니다. IPv4에는 존재하지만 IPv6에는 없는 필드가 있고 그 반대의 경우도 존재합니다. IPv6는 IPv4 포맷을 개편하여 보다 효율적이고 단순한 구조를 갖도록 개선한 것입니다.

5. 인터넷 제어 메시지 프로토콜 (ICMP)

ICMP 프로토콜은 네트워크 상에서 오류 메시지를 전송하기 위해 만들어졌습니다. IP 프로토콜과 함께 작동하며 네트워크 통신 문제를 진단하는 데 도움을 줍니다. ICMP는 주로 데이터가 최적의 방식으로 목적지에 도달하고 있는지를 확인하는 데 사용됩니다.

다음은 ICMP 헤더의 형식입니다.

ICMP 헤더의 구조를 나타낸 이미지입니다. 첫 번째 줄은 비트 구간을 4개의 필드로 나눈 형태이며, 각각 Type(0에서 7비트), Code(8에서 15비트), Checksum(16에서 31비트)으로 구성되어 있습니다. 두 번째 줄에는 32비트 전체를 사용하는 Header Information 필드가 위치해 있습니다.

ICMP는 오류 메시지를 전송하는데 이때 해당 오류의 종류는 코드(code)와 타입(type) 값을 통해 정의됩니다. 체크섬(checksum)을 통해 메시지의 정확성을 검증하며 오류에 대한 추가 정보는 헤더 정보(header information) 필드에 저장됩니다.

ICMP는 IP와는 달리 비연결형(connectionless) 프로토콜입니다. ICMP 메시지를 한 시스템에서 다른 시스템으로 전송할 때 시스템 간에 연결을 설정할 필요가 없습니다.

일반적으로 ICMP는 라우터와 같은 네트워크 장치에서 사용됩니다. 또한 분산 서비스 거부(DDoS) 공격에도 활용될 수 있습니다.

6. 주소 결정 프로토콜 (ARP)

컴퓨터 애플리케이션은 다른 애플리케이션과 통신하기 위해 논리 주소를 사용합니다. 그러나 실제 통신을 위해서는 물리 주소(MAC 주소)가 필요합니다. 이때 사용되는 것이 바로 주소 결정 프로토콜(Address Resolution Protocol)입니다.

ARP는 네트워크 주소를 데이터 링크 계층에서 사용하는 물리 주소로 매핑하는 프로세스를 수행합니다. 다시 말해 네트워크 상의 특정 컴퓨터의 물리 주소를 찾는 프로세스입니다. ARP는 OSI 모델에서 네트워크 계층의 주소를 데이터 링크 계층의 주소로 변환합니다.

MAC 하드웨어 주소를 확인하기 위한 ARP 메시지 구조 예시는 다음과 같습니다.

이 이미지는 ARP 메시지의 헤더 구조를 나타낸 것입니다. 첫 번째 줄은 비트 0에서 31 구간에 대해 Hardware Type(0에서 15비트), Protocol Type(16에서 31비트) 필드가 위치해 있으며, 그 아래에는 Hardware Address Length(HLEN)(0에서 8비트), Protocol Address Length(PLEN)(9에서 15비트), Operation(16에서 31비트) 필드가 배치되어 있습니다. 이후에는 송신자의 하드웨어 주소(Sender HA)와 IP 주소(Sender IP), 수신자의 하드웨어 주소(Target HA)와 IP 주소(Target IP)가 순차적으로 나열되어 있으며, 각 주소는 바이트 단위로 세부 위치가 명시되어 있습니다.

ARP는 네트워킹 과정에서 가장 중요한 구성 요소 중 하나이며 일반적으로 인터넷 프로토콜 스위트와 함께 사용됩니다.

7. 전송 제어 프로토콜 (TCP)

전송 제어 프로토콜(Transmission Control Protocol)은 애플리케이션 프로그램 간 데이터 교환을 위해 네트워크 연결을 설정하고 유지하는 방법을 정의하는 표준입니다. TCP는 IP 위에서 동작하여 데이터 패킷의 신뢰성 있는 전송을 보장합니다.

TCP는 연결 지향적이고 신뢰성이 높은 프로토콜입니다. 두 장치가 TCP를 통해 데이터를 교환하려면 먼저 연결을 설정해야 합니다. 또한 데이터 전송 상태에 대한 확인 응답(ACK)을 송신 측에 전달하여 데이터가 제대로 전송되었는지를 알립니다. 만약 부정 응답(NAK)이 수신되면 송신자는 해당 데이터를 다시 전송합니다.

이미지는 TCP 연결 수립 과정인 3-way 핸드셰이크를 설명하는 그림입니다. 왼쪽에는 송신자(Sender), 오른쪽에는 수신자(Receiver)가 있으며, 송신자가 먼저 Syn 패킷을 전송하고, 수신자가 이에 대해 Syn Ack를 응답한 뒤, 송신자가 최종적으로 Ack 패킷을 보내는 총 세 단계의 흐름이 화살표로 순차적으로 표현되어 있습니다.

데이터 전송 중 일부 데이터가 유실되거나 오류가 발생할 수 있기 때문에 TCP는 오류 검출 및 복구 메커니즘을 통해 이러한 상황에 대응합니다.

TCP는 직접적인 연결을 사용하는 방식이므로 TCP 패킷 헤더에는 출발지 포트와 목적지 포트 정보가 포함되어 있어야 네트워크 내에서 메시지를 교환할 수 있습니다.

이미지는 TCP 헤더의 구조를 나타낸 것입니다. 헤더는 여러 필드로 구성되어 있으며, 상단부터 Source Port(16비트)와 Destination Port(16비트), Sequence Number(32비트), Acknowledgment Number(32비트), Data Offset(4비트), Reserved(3비트), Flags(9비트), Window Size(16비트), Checksum(16비트), Urgent Pointer(16비트), 마지막으로 Options(32비트) 필드 순으로 나열되어 있습니다. 각 필드는 색상으로 구분되어 시각적으로 구성 요소를 쉽게 파악할 수 있도록 되어 있습니다.

TCP 프로토콜은 SSH, FTP, HTTP를 통한 웹 접근, 월드 와이드 웹(World Wide Web), 이메일 등 다양한 애플리케이션에서 사용됩니다.

8. 사용자 데이터그램 프로토콜 (UDP)

사용자 데이터그램 프로토콜(User Datagram Protocol)은 지연에 민감한 전송을 위해 인터넷 네트워크에서 사용되는 전송 계층 프로토콜입니다. 이 프로토콜은 별도의 연결 과정을 거치지 않고 메시지를 전송하기 때문에 데이터 전송 속도가 매우 빠릅니다.

UDP는 비연결형이며 신뢰할 수 없는 프로토콜입니다. TCP와 달리 패킷 손실이 발생했을 경우 재전송 메커니즘이 없으며 오류 검출 프로세스 또한 전혀 없습니다. 하지만 지연 시간과 대역폭 측면에서는 TCP보다 훨씬 더 효율적입니다.

TCP는 연결된 장치들 간의 데이터 흐름을 유지하기 때문에 전송된 메시지에 대해 항상 동기화와 수신 확인이 필요합니다. 반면 UDP는 이러한 연결 상태를 유지하지 않기 때문에 송신 장치는 수신 확인 메시지를 받을 필요 없이 요청에 대한 응답을 계속해서 전송할 수 있습니다.

UDP 통신 흐름을 나타낸 그림입니다. 왼쪽에는 송신자(Sender), 오른쪽에는 수신자(Receiver)가 있으며, 송신자가 하나의 요청(Request)을 보내고, 수신자로부터 여러 개의 응답(Response)이 순차적으로 도착하는 모습이 화살표로 표현되어 있습니다. 이는 UDP가 연결 기반이 아닌 비연결형 프로토콜임을 시각적으로 보여줍니다.

이제 UDP 헤더의 형식을 살펴 보겠습니다.

이미지는 UDP 헤더의 구조를 나타낸 것입니다. 헤더는 총 4개의 필드로 구성되어 있으며, 각각 Source Port(2바이트), Destination Port(2바이트), Length(2바이트), Checksum(2바이트)로 구성되어 있습니다. 각 필드는 색상으로 구분되어 있으며, 동일한 크기의 블록 형태로 나열되어 있습니다.

UDP와 TCP의 더 자세한 차이는 UDP와 TCP를 비교한 글을 참고하세요.

UDP는 화상 통신, 온라인 게임, 실시간 영상 스트리밍 등 실시간 서비스에서 사용됩니다.

9. 하이퍼텍스트 전송 프로토콜 (HTTP)

하이퍼텍스트 전송 프로토콜(Hypertext Transfer Protocol)은 월드 와이드 웹(WWW)의 기반을 이루는 프로토콜로 하이퍼텍스트 링크를 통해 웹 페이지를 불러오는 데 사용됩니다. HTTP는 애플리케이션 계층 프로토콜입니다. 이를 통해 사용자는 사용자 친화적인 인터페이스로도 네트워크에 연결된 장치 간에 정보를 전달할 수 있습니다. HTTP는 애플리케이션이 사용자와 통신할 수 있도록 도와주는 역할을 하는 것입니다.

웹 클라이언트란 일반적으로 웹 브라우저와 같은 사용자 애플리케이션을 의미하며 서버는 대개 클라우드에 존재하는 컴퓨팅 시스템입니다. 웹 클라이언트가 WWW를 통해 웹 서버와 통신하고자 할 때 HTTP 요청(request)을 서버로 보냅니다. 서버는 요청을 수신하면 이를 처리한 뒤 HTTP 응답(response)을 클라이언트에게 전송합니다. 이후 클라이언트는 그 응답을 수신하여 처리합니다.

HTTP 요청 헤더와 HTTP 응답 헤더가 동일하지 않다는 점에 유의해야 합니다.

HTTP 요청과 응답의 구조를 설명하는 그림입니다. 왼쪽에는 클라이언트 장치, 오른쪽에는 서버가 위치해 있으며, 클라이언트가 서버로 HTTP Request를 보내고 서버가 이에 대한 HTTP Response를 반환하는 방향이 화살표로 표시되어 있습니다. HTTP 요청 헤더는 HTTP Version Type, URL, HTTP Method, Request Headers, Optional HTTP Body 순으로 구성되어 있으며, 이는 상단 박스에 색상으로 구분되어 나타나 있습니다. 하단에는 HTTP 응답 헤더의 구성 요소로 HTTP Status Code, Response Headers, Optional HTTP Body가 나열되어 있으며, 각 항목은 시각적으로 구분된 색상 블록으로 표현되어 있습니다. 이 이미지는 HTTP 통신의 양방향 흐름과 메시지 구조를 시각적으로 보여줍니다.

HTTP는 비연결형이자 무상태 프로토콜입니다. 클라이언트와 서버는 통신이 이루어지는 동안에만 서로를 인식하며 통신이 완료되면 서로에 대한 정보를 기억하지 않습니다. 또한 HTTP는 미디어 독립 프로토콜로 어떠한 타입의 데이터도 전송할 수 있습니다.

10. 동적 호스트 구성 프로토콜 (DHCP)

동적 호스트 구성 프로토콜(Dynamic Host Configuration Protocol)은 IP 네트워크에서 작동하여 네트워크에 연결된 장치나 호스트에 IP 주소를 자동으로 할당하는 역할을 합니다. 또한 장치들이 서로 효율적으로 통신할 수 있게 합니다.

DHCP는 단순히 IP 주소만 할당하는 것이 아니라 서브넷 마스크, 기본 게이트웨이 주소, 도메인 네임 서버(DNS) 주소, 그 외 관련된 네트워크 구성 매개변수도 함께 제공합니다.

클라이언트 장치는 DHCP 서버에 탐색 메시지를 전송하고 DHCP 서버는 이에 대해 제안 메시지를 응답으로 보냅니다. 이후 클라이언트는 요청을 보내고 DHCP 서버는 해당 요청을 승인하여 할당을 확정합니다.

이미지는 DHCP 통신 과정에서의 4단계 절차를 나타낸 그림입니다. 왼쪽에는 클라이언트(Client), 오른쪽에는 DHCP 서버(DHCP Server)가 배치되어 있으며, 클라이언트가 Discover 메시지를 서버로 전송한 후, 서버는 Offer 메시지를 응답합니다. 이후 클라이언트가 Request 메시지를 보내고, 서버가 최종적으로 Ack 메시지로 응답하는 일련의 흐름이 네 개의 화살표로 표현되어 있습니다. 이는 DHCP 주소 할당 과정의 기본적인 동작 절차를 시각화한 것입니다.

다음은 DHCP 헤더의 형식입니다.

DHCP 메시지의 헤더 구조를 나타낸 이미지입니다. 첫 번째 줄에는 Operation Code, Hardware Address Type, Hardware Address Length, Hops 필드가 각각 8비트 단위로 나뉘어 있으며, 이후에는 Client ID, Start Time, Flags, Client Address, Offered Address, Server Address, Relay Agent Address, Client Hardware Address, Server Name, File Name, Options 필드가 순서대로 배치되어 있습니다. 각 필드는 DHCP 통신에 필요한 주소 정보 및 제어 정보를 담고 있으며, 표 형식으로 정렬되어 있습니다.

11. 스패닝 트리 프로토콜 (STP)

IEEE 802.1D로 정의된 스패닝 트리 프로토콜(Spanning Tree Protocol)은 LAN 내에서 발생할 수 있는 루프를 방지하기 위해 고안된 프로토콜입니다. STP는 브리지를 사용하는 네트워크에서 발생하는 문제들을 해결하는 데 사용됩니다. 중복된 링크를 제거하고 네트워크 변경이나 장애 상황에 적절히 대응합니다.

STP는 네트워크에 존재하는 모든 링크를 모니터링합니다. 그리고 링크 간의 문제나 중복 링크가 발견되면, 신장 트리 알고리즘(STA)을 적용합니다. STA는 현재의 네트워크 구조를 기반으로 하나의 트리 형태의 토폴로지(topology)를 구성하고 불필요한 중복 링크를 비활성화합니다. 새로운 링크가 기존 네트워크에 추가될 경우 STP는 STA를 다시 실행하여 해당 링크가 중복되지 않도록 확인합니다.

STP는 구성 메시지(configuration message)를 프로토콜 프레임으로 사용합니다. STP를 지원하는 네트워크 장치들은 이 구성 메시지를 서로 주고받으며 스패닝 트리를 생성합니다. 다음은 구성 메시지의 표준 포맷 예시입니다.

프레임은 왼쪽부터 오른쪽으로 총 다섯 개의 필드로 구성되어 있으며, 각 필드는 색상으로 구분되어 있습니다. 순서대로 Source MAC Address(6바이트), Destination MAC Address(6바이트), Frame Length(2바이트), Logical Link Control Header(3바이트), Payload(35바이트)로 구성되어 있습니다. 각 필드에는 필드명과 크기가 함께 표시되어 있어 프레임 구성 요소를 시각적으로 확인할 수 있도록 구성되어 있습니다.

12. 파일 전송 프로토콜 (FTP)

파일 전송 프로토콜(File Transfer Protocol)은 TCP/IP 위에서 작동하는 표준 네트워크 프로토콜로 한 서버에서 다른 서버로 파일을 전송하는 데 사용됩니다. FTP는 신뢰성과 효율성을 갖춘 파일 전송 기능을 제공합니다.

한 서버에서 다른 서버로 파일을 전송하는 것은 단순한 작업처럼 보일 수 있지만 실제로는 다양한 문제가 발생할 수 있습니다. 송신 시스템과 수신 서버간 파일 형식이나 데이터 표현 방식이 다를 수 있고, 경우에 따라서는 두 시스템의 디렉터리 구조 역시 서로 다를 수 있습니다. FTP는 이러한 문제들을 해결해 줍니다.

두 시스템간 파일을 전송할 때 FTP는 두 개의 연결을 설정합니다. 하나는 데이터 전송용 연결, 다른 하나는 제어 연결입니다.

이 이미지는 FTP(File Transfer Protocol)의 구조를 설명하는 다이어그램입니다. 왼쪽에는 클라이언트(Client), 오른쪽에는 서버(Server)가 표시되어 있으며, 각 구성 요소는 박스 형태로 나뉘어 있습니다. 클라이언트 측에는 상단부터 순서대로 User Interface, Control Process, Data Transfer Process가 위치해 있고, 서버 측에는 Control Process와 Data Transfer Process 두 가지 구성 요소가 표시되어 있습니다. 클라이언트의 Control Process는 서버의 Control Process와 TCP/IP 기반의 Control Connection으로 연결되어 있으며, Data Transfer Process는 서버의 Data Transfer Process와 TCP/IP 기반의 Data Connection으로 연결되어 있습니다. 이 그림은 FTP에서 제어 연결과 데이터 전송 연결이 각각 독립적으로 구성되어 동작하는 구조를 시각적으로 보여줍니다.

FTP의 장점은 속도와 효율성에 있습니다. 또한 보안 기능도 제공합니다. 사용자는 FTP 서버에 접근하려면 사용자 이름과 비밀번호를 입력해야 합니다. FTP는 데이터를 양방향으로 전송할 수 있는 기능을 지원합니다. 따라서 송신자와 수신자 모두 서로에게 데이터를 보낼 수 있습니다.

다만 FTP에는 몇 가지 단점도 있습니다. 전송 가능한 데이터 크기는 2GB로 제한됩니다. 따라서 2GB보다 큰 파일은 FTP로 전송할 수 없습니다. 또한 모든 시스템과의 호환성이 보장되지는 않습니다.

13. 보안 셸 (SSH)

보안 셸(Secure Shell)은 보안되지 않은 네트워크 환경에서도 네트워크 서비스를 안전하게 사용할 수 있도록 암호화 기술을 사용하는 네트워크 프로토콜입니다. 원격 명령 실행이나 원격 시스템 접근과 같은 다양한 애플리케이션들이 SSH를 통해 안전하게 수행될 수 있습니다. SSH에 대한 보다 자세한 내용은 SSH 소개 글에서 확인할 수 있습니다.

14. SSH 파일 전송 프로토콜 (SFTP)

Secure FTP라고도 불리는 SSH 파일 전송 프로토콜(SSH File Transfer Protocol)은 원격 시스템 간의 파일 전송 시 연결을 안전하게 보호하기 위해 사용되는 프로토콜입니다. SFTP는 공개 키 암호화 방식을 사용하여 인터넷상에서의 통신을 보호하고 강력한 사용자 인증 기능도 제공합니다. 이 프로토콜은 2006년 IETF(Internet Engineering Task Force)에 의해 쉘 기반 프로토콜에 보안성을 더하기 위한 목적으로 개발되었습니다.

사용자는 두 가지 방식, 비밀번호 인증 또는 공개키/개인키 기반 인증 방식 중 하나를 통해 SFTP 서버와의 연결을 설정할 수 있습니다.

FTP가 데이터를 전송할 때 두 개의 연결을 사용하는 것과 달리 SFTP는 단일 연결로 파일을 전송할 수 있습니다. 이로 인해 서버 관리자 입장에서는 연결 관리가 더 용이해집니다.

이 이미지는 인터넷을 통한 보안 통신 과정, 특히 데이터 암호화 및 복호화 과정을 설명하는 흐름도입니다. 왼쪽에는 송신자(Sender)가 있고, 오른쪽에는 수신자(Receiver)가 있으며, 송신자가 보낸 평문(Plain Text)은 암호화되어 Encrypted Text가 되고, 이후 Secure Text로 포장되어 인터넷을 통해 전송됩니다. 수신 측에서는 이 과정을 역순으로 따라 Secure Text를 받고 이를 복호화하여 Encrypted Text, 다시 Plain Text로 변환한 후 수신자에게 전달하는 구조로 되어 있습니다. 각 단계는 텍스트 상자와 화살표로 연결되어 있어 데이터가 어떤 순서로 처리되는지를 시각적으로 보여줍니다.

또한 SFTP는 파일을 이진(binary) 형식으로 전송하므로 전송 속도가 훨씬 빠릅니다. 파일 권한 및 속성 조작, 파일 잠금 등 다양한 파일 관련 작업도 지원합니다.

15. 결론

이 튜토리얼에서는 가장 널리 사용되고 매우 인기 있는 12가지 네트워크 프로토콜에 대해 살펴보았습니다. 각 프로토콜에 대한 간단한 소개와 몇몇 적용 사례를 함께 다뤘습니다.

제시된 프로토콜들은 효율성이나 복잡성 측면에서 일부 한계를 가질 수 있음에도 여전히 네트워킹 기술에서 가장 많이 사용되는 표준으로 자리 잡고 있습니다.

프로토콜은 네트워크를 통한 안전한 정보 공유 시스템을 올바르게 구축하고 운영하기 위해 설계되고 개발되었습니다. 이러한 방식의 통신에 대부분의 기업과 조직이 의존하게 되었고, 이를 통해 사람들은 인터넷상에서 지식과 경험을 나누고 받을 수 있게 되었습니다.

0
Subscribe to my newsletter

Read articles from Ahra Yi directly inside your inbox. Subscribe to the newsletter, and don't miss out.

Written by

Ahra Yi
Ahra Yi