[네트워크 기초]OSI 7계층과 HTTP의 진화, Socket과 Port의 차이점

네트워크, 보안, 프로토콜/네트워크 기초

[네트워크 기초]OSI 7계층과 HTTP의 진화, Socket과 Port의 차이점

마손(Mason) 2022. 3. 9. 23:02

네트워크에 대해 학습할 것이다.

직접 만들어 보았던 WAS도 앞으로 사용해볼 AWS와 같은 클라우드 서비스도 모두 네트워크를 통해 이루어진다.

따라서 네트워크에 대해 아는 것은 DevOps 엔지니어로써 서버를 유지, 보수하기 편하다고 생각한다.

OSI 7계층과 TCP/IP 4계층

네트워크라 하면 보통 이 그림이 먼저 떠오른다. 근데 대체 왜 나눌까?

이는 엔지니어로써 네트워크에 문제가 발생하였을때, 대체 어디서 문제가 발생했는지 빠르게 알아내고 해결해 나가기 위함이다.

따라서 각 계층의 역할과 종류, 기능을 학습할 필요가 있다. 더욱이 어떻게 활용되는지 깊게 알아보면 좋을 것이다.

OSI 7계층과 TCP/IP 4계층으로 왜 나눌까?

두 계층은 위 그림처럼 명확하게 구분되지는 않는다.

네트워크 계층의 IP와 전송 계층의 TCP가 가장 많이 사용된다.

현재 대부분의 데이터 통신이 TCP와 IP기반으로 이루어져있다.

그래서 따로 TCP/IP 4계층을 만든 것 같다.

애플리케이션 개발자 입장

물리 계층에 가까운 부분을 하위 계층, 애플리케이션에 가까운 부분을 상위 계층이라 부른다.

따라서 애플리케이션을 개발하는 개발자는 하향식으로 네트워크를 바라보게 된다. 간단하게 계층별로 알아보면 다음과 같다.

OSI L7: 애플리케이션(응용) 계층, 애플리케이션 프로세스를 정의하고, 애플리케이션 서비스를 수행한다. HTTP등이 사용된다.
OSI L6: 프레젠테이션(표현) 계층, 번역기 같은 역할을 수행한다. 인코딩이나 암호화, 압축, 코드 변환과 같은 동작을 수행한다.
OSI L5: 세션 계층, 양 끝 단의 프로세스 간 연결을 성립하도록 도와주고, 작업을 마친 후에는 연결을 끊는 역할을 한다.
OSI L4: 전송 계층, 해당 데이터들이 실제로 정상적으로 보내지는지 확인하는 역할을 한다.
OSI L3: 네트워크 계층, IP주소와 같은 논리적인 주소를 정의한다. 그리고 라우터를 통해 정의한 IP주소를 이해하고, 최적의 경로를 찾아 패킷을 전송한다.
OSI L2: 데이터 링크 계층, 물리 계층에서 들어온 전기 신호를 모아 알아 볼 수 있는 데이터 형태로 처리한다. 주소 정보를 정의하고 출발지와 도착지 주소를 확인한 후, 데이터 처리를 수행한다. MAC주소가 사용된다.
OSI L1: 물리 계층, 말 그대로 물리적 연결과 관련된 정보를 정의한다. 들어온 전기 신호를 그대로 잘 전달하는 것이 목적이다.

각 계층을 자세히 알아보자

OSI L7 애플리케이션(응용) 계층

해당 계층에서 가장 익숙한 것이 HTTP이다. 이는 전에 공부한 적 있다.

이번에는 HTTP의 진화 과정을 버전별로 살펴보고 차이점을 학습할 것이다.

초기 HTTP

HTTP는 월드 와이드 웹에 내재된 프로토콜이다. 본래 단순한 텍스트파일을 전송하는 것에서 현재 이미지와 비디오까지 전송할 수 있도록 발전했다.

초기에는 하이퍼텍스트 문서를 표현하기 위한 텍스트 형식인 하이퍼텍스트 마크업 언어(HTML),

문서 교환을 위한 간단한 하이퍼텍스트 전송 프로토콜(HTTP),

문서를 클라이언트 화면에 나타내주는 월드 와이드 웹이라는 첫번째 브라우저,

해당 문서에 접근하도록 해주는 httpd의 초기버전.

이 4개로 구성되었다.

HTTP/0.9: One-line Protocol

요청은 극히 단순히 한줄로 구성되었고 메소드도 GET이 유일했다.

GET /mypage.html

응답도 오로지 파일 내용 자체로 구성되었다. 상태 코드, 헤더 어떠한 것도 없었다.

<HTML>
A very simple HTML page
</HTML>

HTTP/1.0

HTTP 버전 정보가 표시되었다.

상태 코드가 표시되어, 브라우저가 요청에 대한 성공과 실패 여부를 판단하고 행동할 수 있게 되었다.

헤더를 도입하여 확장성을 넓혔다. 대표적으로 Content-Type으로 더 많은 확장자의 파일을 전송할 수 있게 되었다.

요청 예시

GET /mypage.html HTTP/1.0
User-Agent: NCSA_Mosaic/2.0 (Windows 3.1)

200 OK
Date: Tue, 15 Nov 1994 08:12:31 GMT
Server: CERN/3.0 libwww/2.17
Content-Type: text/html
<HTML>
A page with an image
  <IMG SRC="/myimage.gif">
</HTML>

응답 예시

GET /myimage.gif HTTP/1.0
User-Agent: NCSA_Mosaic/2.0 (Windows 3.1)

200 OK
Date: Tue, 15 Nov 1994 08:12:32 GMT
Server: CERN/3.0 libwww/2.17
Content-Type: text/gif
(image content)

HTTP/1.1

우선 예시를 보자

GET /en-US/docs/Glossary/Simple_header HTTP/1.1
Host: developer.mozilla.org
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:50.0) Gecko/20100101 Firefox/50.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Referer: https://developer.mozilla.org/en-US/docs/Glossary/Simple_header

200 OK
Connection: Keep-Alive
Content-Encoding: gzip
Content-Type: text/html; charset=utf-8
Date: Wed, 20 Jul 2016 10:55:30 GMT
Etag: "547fa7e369ef56031dd3bff2ace9fc0832eb251a"
Keep-Alive: timeout=5, max=1000
Last-Modified: Tue, 19 Jul 2016 00:59:33 GMT
Server: Apache
Transfer-Encoding: chunked
Vary: Cookie, Accept-Encoding

(content)


GET /static/img/header-background.png HTTP/1.1
Host: developer.mozilla.org
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:50.0) Gecko/20100101 Firefox/50.0
Accept: */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Referer: https://developer.mozilla.org/en-US/docs/Glossary/Simple_header

200 OK
Age: 9578461
Cache-Control: public, max-age=315360000
Connection: keep-alive
Content-Length: 3077
Content-Type: image/png
Date: Thu, 31 Mar 2016 13:34:46 GMT
Last-Modified: Wed, 21 Oct 2015 18:27:50 GMT
Server: Apache

(image content of 3077 bytes)

Host 헤더 덕분에, 동일 IP 주소에 다른 도메인을 호스트하는 것이 가능해졌다.

컨텐츠 협상이 도입되어, 클라이언트에 요구에 맞는 언어 혹은 인코딩이 가능하게끔 했다.

Cash-Control 매커니즘이 도입되었다.

Chunked 데이터도 전송이 가능해졌다.

파이프라인을 추가하여 첫번째 요청에 대한 응답이 완전히 전송되기전, 두번째 요청 전송을 가능케 하여, 레이턴시를 낮췄다.

여기까지가 내가 아는 HTTP의 버전 정보이다.

HTTP/2

구글의 SPDY(스피디)를 기반으로 작성된 것으로, TLS를 통해 항상 암호화되어 전송되고, 압축, 다중화, 우선 순위 설정을 통해 레이턴시 감소를 달성했다.

하나의 소켓 연결을 통해 여러 하위 요소를 한꺼번에 전송받을 수 있다. 따라서 웹페이지 로딩시간 감소를 기대할 수 있다.

기존 HTTP 헤더는 사람이 읽을 수 있는 헤더를 담고있던 것과 달리, 압축 알고리즘을 이용하여 이진화되어 저장되므로 적은 용량이 사용된다.

HTTP/3

이것은 아직 잘 사용되지는 않는다. 필요하다면 그때 그때 검색해보자!

OSI 4: 전송계층(Transport Layer)

이 계층에서는 데이터들이 복잡한 네트워크 망에서 잘 전송되었는지 확인한다.

이 때 소켓(Socket)과 포트(Port)라는 것이 등장한다. 이것들은 무엇일까?

소켓과 포트는 데이터 전송과 관련된 길잡이 역할을 동일하게 수행하지만, 조금 다르다.

포트

프로세스를 가르키는 번호다.
네트워크 프로세스에 부여된 논리적인 구조다.
포트번호로 시스템 내에서 프로세스를 찾을 수 있다. 따라서 다른 컴퓨터가 같은 소프트웨어를 사용하고 있다면 두 컴퓨터는 같은 포트번호를 쓴다.
참고로 1024번 아래의 번호는 잘 알려진(Well-known) 포트번호로 널리 사용되는 서비스에 이미 배정되어 있다. 예시로 http는 80번, https는 443번을 쓰는 것처럼 말이다.

소켓

IP 주소와 포트번호의 조합이다.
따라서 해당 컴퓨터(machine)와 서비스를 알아내어 접근할 수 있다.