들어가면서..

이 포스팅의 목적은 토마스님이 진행하는 컴퓨터 네트워크 스터디에 참여하면서 지금까지 알고있던 네트워크 지식들을 정리하고 되돌아보기위해 1주일 동안 공부한 내용을 정리하여 올리는 것입니다.

네트워크 개요

우리는 일상에서 웹 사이트를 들여다보고, 웹 상에서 구현된 유능한 서비스들을 이용하고 있습니다. 바로 인터넷에 수 많은 웹 사이트가 등재되어있기 때문인데요.😄 웹 사이트라는 용어는 다들 친숙하시겠지만 한번 짚고 넘어가자면 웹 서버 애플리케이션이 공개하는 다양한 웹 페이지의 집합이라고 볼 수 있습니다. 여기서 웹 페이지는 일반적으로 HTML이라는 문법으로 작성된 HTML 파일로 이루어져 있고 이 페이지를 요청할 때 항상 한 번으로 끝나는 것은 절대 아닙니다.

결국 많은 서비스를 이용하기 위해 웹 사이트에 방문하는 행위는 웹 서버가 필요하고, 웹 서버는 대부분 저~멀리 떨어져 있습니다. 웹 서버도 컴퓨터로 구현한 것이기 때문에 컴퓨터와의 통신이 필요하고 수 많은 그물망 처럼 서로 얽혀 있습니다. 네트워크를 한마디로 표현하자면 컴퓨터끼리 데이터를 주고 받는 시스템이라고 볼 수 있습니다.

프로토콜

네트워크를 공부하다보면 항상 등장하는 것이 프로토콜과 계층(Layer) 입니다. 컴퓨터 통신에서는 네트워크 아키텍처를 이용하는데 이는 통신을 위해 의사소통을 하기 위한 일종의 언어적 수단이라고 볼 수 있습니다. 네트워크 아키텍처도 다른 언어와 마찬가지로 일종의 규칙, 데이터 형식이 필요하는데 이렇게 통신에 필요한 규칙을 프로토콜이라고 합니다. 즉, 프로토콜의 집합이 네트워크 아키텍처라고 볼 수 있습니다.

네트워크 아키텍처의 종류

• TCP/IP
• OSI
• Microsoft NETBEUI
• Novell IPX/SPX
• Apple Appletalk
• IBAM SNA

이렇게 네트워크 아키텍처는 수많이 존재하지만, 대다수의 웹 서비스는 TCP/IP를 사용합니다. TCP/IP는 애플리케이션 데이터 송수신을 위해 역할별로 4가지 계층화된 프로토콜로 구성됩니다. 여기서 ‘계층화’란 각 역할별로 경계를 두면서 추후 프로토콜 기능 변경이 쉽도록 하는 것을 의미합니다.

OSI 7계층

OSI는 Open System Interconnection의 약자로, ISO에서 제안한 네트워크 통신에 사용할 수 있는 표준적인 네트워크 아키텍처입니다. 세부적으로 7개의 계층으로 이루어져 있습니다.

물리 계층
통신 단계에서의 최하위 계층으로 전기적, 기계적, 기능적인 특성을 이용해서 통신 케이블로 데이터를 전송하는 단계입니다. 이 계층에서 사용되는 통신 단위는 Bit이며 0과 1로 나타낼 수 있는 전기적인 신호 입니다.

• 통신 케이블(LAN 케이블 등), 리피터, 허브

데이터링크 계층
물리 계층은 송수신되는 정보의 오류와 흐름을 관리하는 단계로, 안전한 정보의 전달을 수행하도록 도와줍니다. 이 계층은 통신에서의 오류를 찾아주고 문제가 발생했을 때 재전송도 가능하며, MAC 주소를 가지고 통신을 수행합니다.

• 브리지, L2 스위치

네트워크 계층 목적지까지 가장 안전하고 빠르게 전달하는 기능을 수행하는 계층입니다. 이 과정을 라우팅이라고 합니다. 이 계층에 속하는 장비가 라우터이며 라우터는 목적지의 경로를 선택하고, 주소를 정하며 경로에 따라서 데이터 패킷을 전달해주는 기능을 수행합니다. (스위치 장비 중 라우팅 기능까지 수행하는 스위치를 L3 스위치라고 합니다.)

• 라우터, L3 스위치, IP

전송 계층
전송 계층에서는 플로우 컨트롤과 오류 복구 기능을 수행합니다. 이러한 기능들은 데이터 전송 시 패킷을 재전송하거나 플로우를 조절하여 데이터를 정상적으로 전송할 수 있도록 합니다. 플로우 컨트롤은 TCP에서 제공하는 기능으로, 네트워크가 혼잡할 때 데이터 전송 속도를 제어합니다.

• TCP, UDP

센션 계층, 표현 계층, 응용 계층

• 세션 계층: 두 컴퓨터 간의 TCP/IP 세션 또는 데이터 전송을 관리하며 포트끼리 연결되어 있는 계층입니다. 종단 통신 장비 간의 송수신 방식에 따라 통신을 수행하며, 동기화 역할을 수행합니다.
• 표현 계층: 응용 계층에서 수신된 데이터를 사용자가 읽을 수 있는 형식으로 변환하는 기능을 수행합니다. (인코딩과 디코딩)
• 응용 계층: OSI 7계층 모델에서의 최상위 계층으로 사용자가 네트워크 리소스에 접근하는 방법을 제공합니다. (브라우저, telnet, 전자우편 등)

TCI/IP 4계층

TCP/IP는 TCP와 IP를 중심으로 하는 프로토콜의 집합입니다. PC OS나 스마트폰 OS에 기본적으로 내장되어 있어, 간단하게 이용할 수 있는 장점이 있습니다. 이 프로토콜은 4개의 계층으로 이루어져 있으며, 상위 계층이 정상 동작을 수행하려면 하위 계층이 정상적으로 동작해야 한다는 전제가 있습니다.

네트워크 액세스 계층
같은 네트워크 안에서 데이터를 전송하는 역할을 담당합니다. 여기서 ‘같은 네트워크’는 라우터와 L3 스위치로 구성된 네트워크 또는 L2 스위치로 구성된 네트워크를 의미합니다. 이 계층에서 0과 1로 구성된 디지털 데이터를 전기적 신호로 변환해 전송 매체로 전달해 가는 과정을 수행합니다.

• 유선 이더넷, 무선 LAN(Wi-Fi), PPP

인터넷 계층
수많은 라우터 사이에서 데이터를 전송하는 역할을 수행합니다. 원격지 네트워크에서 데이터 패킷을 목적지까지 전송하는 라우팅 과정이 진행됩니다.

• IP (end-to-end), ICMP, ARP (IP와 MAC주소 대응)

전송 계층
데이터를 적절한 애플리케이션에 배분하는 역할을 수행합니다. TCP와 UDP 프로토콜등이 속해있고, TCP를 사용해 데이터와 패킷이 보내진 순서로 전달하는 것을 보장해줍니다. (신뢰성)

• TCP, UDP, RDP, RTCP

애플리케이션 계층
애플리케이션의 기능을 실행하기 위해 데이터 형식과 처리 절차 등을 결정하는 계층입니다. 실제 사용자가 읽을 수 있는 텍스트나 이미지 등을 표현하기 위해 데이터를 변환합니다.

• HTTP, SMTP(전자메일), POP3(전자메일), DHCP(IP주소정보 지정), DNS(리소스 이름 지정)

HTTP

HTTP의 역할

웹은 지식 공유를 위해 탄생했습니다. 최초로 통신하는 방식은 하이퍼텍스트(HyperText)를 이용해 상호 참조할 수 있는 방식이었습니다. 이것이 바로 World Wide Web의 기본 개념입니다.

문서를 공유하기 위해 SGML 언어를 기반으로 한 HTML(HyperText Markup Language)을 사용합니다. 이 문서를 서로 통신하기 위해 개발된 프로토콜이 HTTP입니다. 요약하자면 정보를 공유하기 위해 HTML 문서를 HTTP 프로토콜을 사용하여 통신하며, 각 문서의 위치는 URL형식의 규칙을 사용해 인식합니다.

HTTP의 발전 과정

HTTP 0.9
1991년에 초안으로 공개된 버전입니다. 헤더라는 개념이 없었고, 단순하게 전체 본문을 요청하고 응답한 후 커넥션을 열고 닫는 기능만 수행했습니다.

HTTP 1.0
정식 사양으로 공개된 첫 HTTP 버전입니다.

• HTTP 메서드 추가 (GET, HEAD, POST)
• 클라이언트 캐시 관리를 위한 헤더 추가
• Content-Encoding 헤더를 통해 전송 시간을 줄임

HTTP 1.1
현재 가장 많이 상용화되어 있는 버전입니다.

• 청크 전송 지원 (스트리밍 데이터 전송 방식, 동적으로 생성된 컨텐츠를 영구적으로 커넥션 맺을 수 있음)
• 응답 속도 향상, 캐시 지원 추가
• 더욱 다양한 메서드 추가 ( PUT, DELETE, TRACE, OPTIONS)

HTTP 2.0
HTTP 1.1 버전의 성능 문제를 해결하기 위해 구글의 SPDY 프로토콜을 기반으로 설계된 HTTP 버전입니다.

• 여러 리소스들을 한번에 병렬 전송 (Head-Of-Line Blocking 문제 해결)
• 헤더를 압축해 전송 시간 최적화

HTTP 요청과 응답

HTTP는 클라이언트로부터 요청이 송신되며, 그 결과가 서버로부터 응답합니다. 반드시 클라이언트 측에서 통신이 시작됩니다. 요청 메시지와 응답 메시지의 구조는 비,짐하마만,시작줄(Start Line)에서만 약간 차이가 있습니다.

요청 메시지(Request)
요청 메시지의 시작줄은 요청메서드, 요청 URL, 프로토콜 버전으로 구성됩니다.

GET /index.html HTTP/1.1
Host: 185.199.108.153:443

응답 메시지(Response)
응답 메시지의 시작줄은 프로토콜 버전, 상태 코드(200, 400..), 사유 구절로 구성됩니다.

HTTP/1.1 200 OK
Content-Length:362
Content-Type:text/html;charset=utf-8
...

메세지의 시작줄 이후에는 헤더와 본문이 위치합니다. 주의 사항은 모든 메시지에서 본문이 항상 존재하는 것이 않기 때문에 본문이 없는 메시지는 빈줄(CRLF)로 구성하는 것이 원칙입니다.

HTTP Header
요청과 응답 메시지의 추가 정보를 제공하는 역할입니다. 기본적으로 이름/값 형태로 이루어진 목록 형태로 구성할 수 있습니다. 아래에는 각 헤더의 간략한 예시입니다.

• 일반 Header: 요청과 응답 양쪽에 모두 나타낼 수 있습니다.

  Cache-control: no-cache #캐싱 동작을 명시
  Accept: image/gif, image/jpeg, text/html #GIF, JPEGE 형식의 이미지와 HTML만을 허용
  Date: Thu, 14 Sep 2023 17:01:34 GMT #메시지가 전송된 시간
  

• 요청 Header: 요청에 대해 부가 정보를 제공합니다.

  Accept: image/gif, image/jpeg, text/html #GIF, JPEGE 형식의 이미지와 HTML만을 허용
  User-Agent: #요청 클라이언트의 정보 (웹 브라우저, OS 등)
  Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/116.0.0.0 Safari/537.36 Edg/116.0.1938.81
  

• 응답 Header: 응답에 대해 부가 정보를 제공합니다.

  Etag: "c561c68d0ba92bbeb8b0f612a9199f722e3a621a" #웹캐시에 대한 유효성 검증
  Last-Modified: Mon, 18 Jul 2016 02:36:04 GMT #리소스의 마지막 수정 시간
  Server: Apache #웹 서버의 정보
  

• Entity Header: HTTP 본문 크기와 컨텐츠, 리소스 자체를 나타내는 헤더

  Content-Encoding: gzip #압축 방식
  Content-Type: text/html; charset=utf-8 #리소스의 미디어 타입
  Content-Length: 128 #컨텐츠의 길이
  

• 확장 Header: 명세에 지정되어있지 않는 사용자 정의 헤더입니다.

HTTP 메서드

HTTP 메서드는 서버가 어떤 동작을 수행하는지 알리기 위한 역할입니다. GET,HEAD, POST, PUT, DELTE 등 여러 가지 메서드가 존재하며 GET, HEAD 메서드는 서버에 어떠한 작용을 하지 않는 것을 의미하기 때문에 안전한 메서드(Safe Method) 라고 불립니다.

GET
요청 URI를 통해 식별된 리소스를 가져올 수 있도록 요구합니다. 리소스가 텍스트 형태이면 그대로 반환하고, CGI와 같은 프로그램이라면 실행에서 출력된 내용을 반환합니다.

HEAD
GET과 같은 요청 기능이지만 본문을 반환하지 않고, 메세지 헤더만 반환합니다. 주로 URI 검사와 리소스 갱신 시간을 확인하는 데 사용합니다.

OPTIONS
지정한 리소스가 제공하고 있는 HTTP 메서드들을 확인하기 위해 사용합니다.

OPTIONS* HTTP/1.1
HOST: www.jinyisland.kr

HTTP/1.1 200 OK
Allow: GET, POST, HEAD, OPTIONS

POST
서버에 데이터를 전송하기 위해 사용합니다.

PUT
이는 서버에 요청 본문을 작성하기 위해 사용됩니다. 구체적으로 말하면, 요청 본문이 서버에 이미 존재한다면 해당 내용을 수정하고, 요청 본문이 존재하지 않는다면 새로 작성하도록 요청합니다. POST와 비교하자면 POST는 엔티티에 포함된 데이터를 서버에 생성하는 목적으로 사용하고(Create), PUT은 서버의 리소스를 갱신하기 위해서 사용합니다. (Update)

PATCH
리소스의 부분적인 수정을 할 때 사용합니다. PUT과 동작은 비슷하지만 핵심은 멱등성입니다. 멱등성(Idempotent)이란 동일한 요청을 여러번 수행했을 때 동일한 결과로 이어지는 것을 말합니다. PUT, DELETE 와 GET은 멱등적이라고 말할 수 있지만 PATCH는 멱등적이지 않습니다. 다만 메서드 동작 구성에 따라 PATCH도 멱등적으로 동작할 수 있습니다.

//예를 들어 이러한 PUT 요청은 멱등성을 보장합니다.
{id: 'jiny'}

//이러한 요청은 PUT 메서드임에도 멱등적이지 않습니다.
{writeAt: (new Date()).getTime()}

즉, 메서드 설계에서 PUT과 PATCH는 해당 요청이 멱등적으로 동작하는지에 따라 분류할 수 있습니다. 일반적으로 전체 리소스를 변경시키는 PUT에 비해 PATCH는 멱등성을 보장하는 메서드로 이해할 수 있습니다.

DELETE
지정한 리소스를 삭제하기 위해서 사용합니다.

TRACE
웹 서버로부터 자신에게 통신을 되돌려 받는 루프백(Loop Back)을 발생시킵니다. 요청 헤더 Max-Forwards라는 필드에 수치를 설정하고, 웹 서버를 거칠때마다 수치를 줄여나갑니다. 주로 요청 웹서버에 어떤 프록시등이 존재하는지 동작을 확인하기 위해 사용하는데 크로스 사이트 트레이싱(XST)과 같은 보안 이슈도 있기 때문에 많이 사용되지는 않습니다. (XST 공격은 응답 메시지에 웹 서버의 주요 정보 등이 포함될 때 발생할 수 있는 취약점입니다.)

HTTP 상태 코드

모든 HTTP 응답 메시지는 상태 코드와 함께 반환됩니다. 상태 코드는 세 자리 숫자로 구성되며 클라이언트에게 응답 결과를 알려주는 역할을 수행합니다. RFC2016에 명세되어 있지만, 주로 사용하는 것은 14개 정도입니다. 끝 자리가 1~99로 이루어져 있는데, 명세에 나와 있지 않는 숫자도 사용자가 정의해서 따로 사용할 수도 있습니다.

• 1XX: 요청을 받아들여 처리 중 (웹 소켓에서 주로 사용)
• 2XX: 요청 성공
• 3XX: 요청을 완료하려면 추가적인 동작 수행 필요 (Redirect)
• 4XX: 클라이언트 측 에러
• 5XX: 서버 측 에러

참고 자료

• 후니의 쉽게쓴 CISCO 네트워킹 - OSI 레이어는 왜 만들어졌나요? (진강훈 저)
• 그림으로 배우는 HTTP&Network (우에노 센 저)
• HTTP 완벽 가이드 - HTTP 웹의 기초 (데이빗 고울리 저)