'그림으로 배우는 HTTP & Network Basic' 1장~3장

HTTP & Network Basic - 교보문고

---

[제1장, 웹과 네트워크의 기본]

웹은 HTTP 로 나타낸다

클라이언트는 입력란에 지정된 URL에 의지해서 웹 서버에게 의뢰를 하고, 리소스를 얻는다. 이 때 '클라이언트 ~ 서버'까지의 흐름을 HTTP 프로토콜이 결정한다.

멀리 떨어져 있는 팀원과 지식 공유를 하기 위해 WWW 가 고안되었는데, 당시에는 하이퍼텍스트를 열람할 수 있는 클라이언트 애플리케이션의 명칭이었다. 이후 현재에 와서는 웹 브라우저라는 일련의 시스템적인 명칭으로 사용되어 단순히 웹(Web) 이라고 불리고 있다.

네트워크의 기본 TCP/IP

인터넷을 포함하여 일반적으로 사용하고 있는 네트워크는 TCP/IP 라는 프로토콜에서 움직이고 있다. 프로토콜이라는 것은 서로 다른 하드웨어와 운영체제를 가지고 있는 컴퓨터들이 서로 원활하게 통신을 하기 위한 일종의 규약이며 규칙이다. 프로토콜에도 여러 가지가 있는데, 이러한 프로토콜의 집합을 TCP/IP 라고 한다. TCP 와 IP 프로토콜을 가리켜 TCP/IP 라고도 하지만, 범용적으로는 IP 프로토콜을 사용한 통신에서 사용되고 있는 프로토콜을 총칭하는 의미이다. 

TCP/IP 는 application 계층, transport 계층, network 계층, link 계층, 이렇게 크게는 총 4계층으로 나누어져 있다. 이렇게 계층화시킨 이유는 무엇일까? 만약 인터넷이 하나의 프로토콜로만 되어 있다고 한다면 어디선가 사양이 변경되었을 때 전체를 바꿔야 할 것이다. 하지만 계층화되어 있다면 사양이 변경된 해당 부분만 바꾸면 된다. 각 계층은 계층이 연결되어 있는 부분만 결정되어 있고, 각 계층의 내부는 자유롭기 때문이다. 설계 또한 간편해지는 건 당연한 사실이다.

1) application layer : 유저에게 제공되는 애플리케이션에서 사용하는 통신의 움직임을 결정한다. TCP/IP 에는 여러 가지의 공통 애플리케이션이 준비되어 있다. (ex. FTP, DNS, HTTP 등)

2) transport layer : 애플리케이션 계층에 네트워크로 접속되어 있는 2대의 컴퓨터 사이의 데이터 흐름을 제공한다. (ex. TCP, UDP)

3) network layer : 네트워크 상의 패킷의 이동을 다룬다. 패킷이란 전송 데이터의 최소 단위로서, 이 계칭에서는 어떠한 경로를 거쳐 상대방의 컴퓨터까지 패킷을 보낼 지 결정한다. 인터넷의 경우라면 상대 컴퓨터에 도달하는 동안에 여러 대의 컴퓨터와 네트워크 기기를 거쳐 상대방에게 배송된다. 그러한 여러 가지 선택지 중에서 하나의 길을 결정하는 것이 네트워크 계층의 역할이다.

4) link (or datalink) layer : 네트워크에 접속하는 하드웨어적인 면을 다룬다. 운영체제가 하드웨어를 제어하기 때문에 디바이스 드라이버와 네트워크 인터페이스 카드(NIC)를 포함한다. 그리고 케이블 등과 같이 물리적으로 보이는 하드웨어적인 측면도 담당한다.

TCP/IP 통신 흐름

1) 클라이언트 송신 흐름 : 애플리케이션 > 트랜스포트 > 네트워크 > 링크
: 각 계층을 거칠 때 헤더로 불려지는 해당 계층마다 해당 계층에서 필요한 정보를 추가한다.

2) 수신 흐름 : 링크 > 네트워크 > 트랜스포트 > 애플리케이션
: 각 계층을 거칠 때 헤더로 불려지는 해당 계층마다 해당 계층에서 사용한 정보를 삭제한다.

IP/TCP/DNS

 1) IP (Internet Protocol) : IP 는 각 노드에 부여된 주소로서 변경이 가능하며 MAC 주소에 의존해 통신한다. 네트워크 계층에 해당하는 IP 는 각각의 패킷을 IP 주소와 MAC 주소를 이용해 상대방에게 전달하는데, 여러 컴퓨터와 네트워크 기기를 중계하는 동안 ARP 프로토콜을 이용해 수신지의 IP 주소를 바탕으로 다음으로 중계할 곳의 MAC 주소를 찾는 방식으로 목적지를 찾는다. 따라서 목적지까지 중계하는동안 네트워크는 대략적인 목적지만을 알고 있으며, 이 시스템을 라우팅이라고 한다.

*MAC 주소 : 각 네트워크 카드에 할당된 고유 주소이며 변경이 불가능하다.

2) TCP (Transfer Control Protocol) : 트랜스포트 계층에 해당한다. TCP 는 신뢰성 있는 바이트 스트림 서비스를 제공하는데, 대용량 데이터를 작게 분해하여 상대에게 보내고 잘 도착했는 지 확인하는 역할이다. TCP 는 확실하게 전송하는 방법으로 three way handshaking 을 사용한다.

*3 way handshaking : SYN, ACK라는 TCP 플래그를 사용해상대에게 패킷이 잘 보내졌는지 여부를 확인한다. 

1. 송신 시 SYN 플래그로 상대에게 접속하고 패킷 전송
2. 수신 시 ACK 플래그로 송신측에 접속하고 패킷 수신 사실을 전달
3. 송신측이 ACK 플래그를 보내 패킷 교환이 완료되었음을 전달

 이 때 통신이 도중에 끊어지면 동시에 같은 수순으로 패킷을 재전송한다.

3) DNS (Domain Name System) : HTTP와 같이 응용 계층 시스템에서 도메인 이름과 IP 주소 이름 확인을 제공한다. 사람의 언어는 컴퓨터에게는 이해할 수 없는 언어이기 때문에 컴퓨터와 소통하기 위해서는 숫자를 나열하는 방법으로 바꿔야 한다. DNS 는 도메인명에서 IP 주소를 조사하거나, 반대로 IP 주소로부터 도메인명을 조사하는 서비스를 제공한다.

URI 와 URL

URI (Uniform Resource Identifiers) : 웹 페이지를 표시하기 위해 입력하는 주소. 리소스를 식별하기 위해 문자열 전반을 나타낸다.

URL (Uniform Resource Locator) : 스키마를 나타내는 리소스를 식별하기 위한 식별자 (스키마 ->  리소스를 얻기 위한 수단에 이름을 붙이는 방법). 리소스의 장소(=네트워크 상의 위치)를 나타낸다.

http://user:pass@www.example.jp:80/dir/index.htm?uid=1#ch1
스키마://자격정보(크리덴셜)@서버주소:포트번호/계층적 파일 패스?쿼리문자열#프래그먼트 식별자

• 스키마 : 사용할 프로토콜을 뜻하며 웹에서는 http 또는 https를 사용한다.
• 자격정보 : 서버로부터 리소스를 취득하려면 자격정보가 필요하다. 유저명과 패스워드를 지정할 수 있다. 옵션값이다.
• 서버주소 : 접근할 대상(서버)의 도메인명이다.
• 서버 포트 : 서버의 접속 대상이 되는 네트워크 포트 번호를 지정한다. 옵션이며 생략하면 기본값 80이다.
• 계층적 파일 패스 : 특정 리소스를 식별하기 위해서 서버 상의 파일 패스를 지정한다.
• 쿼리 문자열 : 파일패스로 지정된 리소스에 임의의 파라미터를 넘겨주기 위해 쿼리 문자열 사한다. 옵션값이다.
• 프래그먼트 식별자: 취득한 리소스에서 서브 리소스를 가리키기 위해서 사용한다. 옵션값이다.

[제2장, 간단한 프로토콜 HTTP]

HTTP 는 클라이언트와 서버간에 통신을 한다

 HTTP 는 한 번 통신할 때 무조건 클라이언트와 서버가 있다. 클라이언트는 리소스를 요청(=리퀘스트. request) 하는 곳이고, 서버는 리소스 요청을 받아 리소스를 제공(=리스폰스. response) 하는 곳이다. 무조건 통신은 클라이언트에서부터 시작된다. 반드시 클라이언트에서 리퀘스트를 보내며, 서버에서는 리스폰스가 돌아온다.

• 리퀘스트 메세지 : 클라이언트가 리퀘스트를 보내는 양식이다. 메서드, URL 프로토콜 버전, 리퀘스트 헤더 필드와 엔티티로 구성된다.
• 리스폰스 메세지 : 프로토콜 버전, 상태 코드, 상태코드 설명, 리스폰스 헤더 필드와 엔티티로 구성된다.

<HTTP Request>
<메서드> <요청 URL> <프로토콜 버전>
<헤더>
<엔티티 본문>

<HTTP Response>
<프로토콜 버전> <상태 코드> <상태코드 설명>
<헤더>
<엔티티 본문>

상태를 유지하지 않는 프로토콜 HTTP

 HTTP 는 상태를 유지하지 않는 stateless 프로토콜이다. 리퀘스트와 리스폰스를 교환하는 동안에 상태를 관리 하지 않는다. HTTP 프로토콜레벨에서는 이전에 보낸 리퀘스트나 이미 돌려준 리스폰스에 대해서는 기억하지 않는다. 새로운 리퀘스트가 보내질 때 마다 새로운 리스폰스가 생성된다. 많은 데이터를 빠르고 확실하게 처리하는 범위성을 확보하기 위해서 간단하게 설계 되어있다. 하지만 이 특성으론 현재 웹 사이트에서 처리하기 어려운 경우가 생겼다. 로그인처리 등등. 다른페이지를 이동하더라도 로그인이 유지 되어야 한다.

HTTP 메서드

HTTP /1.1에서 사용할 수 있는 메서드이다.

1. GET : 리퀘스트 URI로 식별된 리소스를 가져올 수 있도록 요청한다. 내용은 지정된 리소스를 서버가 해석한 결과이다. 
2. POST : 엔티티를 전송하기 위해 사용한다. GET 만으로도 엔티티를 전송할 수 있지만, 자주 사용하지 않고 POST 를 더 많이 사용한다. GET 과 기능이 비슷하지만 리스폰스에 의한 엔티티를 획득하는 것만이 목적은 아니라는 점에서 GET 과 차이가 있다.
3. PUT : 파일을 전송하기 위해 사용한다. FTP 에 의한 파일 업로드와 같이 리퀘스트 중에 포함된 엔티티를 리퀘스트 URI로 지정한 곳에 보존하도록 요구한다. (=파일 전송) 하지만 PUT 자체에는 인증 기능이 없어 누구나 파일 업로드 가능하다는 보안상의 문제도 있어서 일반적인 웹사이트에서는 사용하지 않는다. 인증기능과 짝을 이루거나 REST 같이 웹끼리 연계하는 설계 양식에서만 사용한다.
4. HEAD : GET 과 같은 기능이지만 메시지 바디는 돌려주지 않는다. URI 유효성과 리소스 갱신 시간을 확인하는 목적 등으로 사용된다.
5. DELETE : 파일을 삭제하기 위해 사용한다. PUT 메서드와는 반대로 동작하며 리퀘스트 URI 로 지정된 리소스의 삭제를 요구한다. 
6. OPTIONS : 리퀘스트 URI로 지정한 리소스가 제공하고 있는 메소드를 조사하기 위해 사용한다.
7. TRACE : 웹 서버에 접속, 자신에게 통신을 되돌려 받는 루프백(loop-back) 발생시킨다. 리퀘스트를 보낸 곳에 어떤 리퀘스트가 가공되어 있는지 조사할 수 있어 프록시 서버 경유 등 origin 서버 접속 시 리퀘스트가 가공될 때 동작 확인 용으로 사용한다. 단, 보안 이슈가 있기에 보통 사용하지 않는다.
8. CONNECT : 프록시에 터널 접속 확립을 요함으로써, TCP 통신을 터널링 시키기 위해 사용된다. 주로 SSL 과 TLS 등의 프로토콜로 암호화된 것을 터널링 시키기 위해 사용한다. 

지속 연결로 접속량 절약 / 파이프라이닝

 지속 연결 (Persistent Connections) : 초기 HTTP에서 발생하는 불필요한 TCP 통신량 문제를 해결하기 위해 고안되었다. 어느 한 쪽이 명시적으로 연결을 종료하지 않는다면 TCP 연결을 계속 유지한다. TCP 커넥션의 오버헤드를 줄임으로써 서버 부하 경감과 웹 페이지의 빠른 표시 구현이 가능하다.

 파이프라인화 (HTTP pipelining) : 지속 연결로 인해, 리스폰스를 기다리지 않고 여러 리퀘스트를 병행해서 보낼 수 있다. 따라서 리퀘스트 수 늘어날 수록 효과가 좋다.

쿠키를 사용한 상태 관리

 HTTP는 지난 리퀘스트와 리스폰스를 관리하지 않기에 과거 상태를 기반으로 현재 리퀘스트를 처리할 수 없다. 이러한 HTTP 의 특징인 stateless 를 유지하면서 상태는 저장하기 위해 쿠키를 도입한다. 쿠키는 리퀘스트와 리스폰스에 쿠키 정보를 추가해 클라이언트의 상태를 파악한다. 

동작 과정 :
- 리스폰스 헤더 필드에 포함되어 클라이언트에 보존된다.
- 클라이언트가 다음 리퀘스트를 보낼 때, 자동으로 쿠키를 함께 송신한다.
- 서버는 받은 쿠키를 이용해 어느 클라이언트인지 확인하고, 서버 상의 기록을 이용해 이전 상태를 파악한다.

[제3장, HTTP 정보는 HTTP 메세지에 있다]

HTTP 메세지

HTTP에서 교환하는 정보는 HTTP 메시지라고 불린다. 리퀘스트메시지, 리스폰스 메시지가 있다. HTTP 메시지는 복수 행(개행 CR+LF)의 데이터로 구성된 텍스트 문자열이다. 크게 구분하면 메시지 헤더와 메시지 바디로 구성되어 있고, 최초에 나타나는 개행 문자로(CR+LF) 메시지 헤더와 바디를 구분한다. 메시지 바디가 항상 존재한다고는 할 수 없다.

메시지 바디와 엔티티 바디의 차이

 HTTP로 데이터를 전송할 때에 인코딩을 하면 전송 효율을 높일 수 있다. 전송할 때 인코딩을 하면 다량의 액세스를 효율 좋게 처리 할 수 있다. 단지 컴퓨터에서 인코딩 처리를 해야 하기 때문에 CPU 등의 리소스는 보다 많이 소비한다.

*인코딩 : 사용자가 입력한 문자나 기호들을 컴퓨터 신호로 바꾸는 것

*디코딩 : 인코딩의 반대 작업

https://velog.io/@chan33344/Codable-%EC%9D%B8%EC%BD%94%EB%94%A9-%EB%94%94%EC%BD%94%EB%94%A9%EC%9D%B4%EB%9E%80

*메시지 : HTTP 통신의 기본 단위로 옥텟 시퀀스로 구성되고 통신을 통해서 전송된다.(octet : 8비트)

*엔티티 : 리퀘스트랑 리스폰스의 페이로드(부가)로 전송되는 정보로 엔티티 헤더 필드와 엔티티 바디로 구성된다.

 HTTP 메시지 바디의 역할은 리퀘스트와 리스폰스에 관한 엔티티 바디를 운반하는 일이다. 기본적으로 메시지 바디와 엔티티 바디는 같지만 전송 코딩이 적용된 경우에는 엔티티 바디의 내용이 변화하기 때문에 메시지 바디와 달라진다.

압축해서 보내는 콘텐츠 코딩

 파일 용량을 zip으로 압축할때가 있다. HTTP에는 이와같이 가능한 콘텐츠 코딩이라고 불리는 기능이 있다. 콘텐츠 코딩은 엔티티에 적용하는 인코딩을 가리키는데 엔티티 정보를 유지한채로 압축한다. 콘텐츠 코딩된 엔티티는 수신한 클라이언트 측에서 디코딩한다.

*콘텐츠 코딩 : 엔티티에 적용되는 인코딩으로 엔티티 정보를 유지한 채로 압축해서 송신하고, 수신 측에서 엔티티를 디코딩한다.
- gzip, compress, deflate, identity 등

*청크 전송 코딩 : HTTP 통신에서 리퀘스트했었던 리소스 전부에서 엔티티 바디 전송이 완료되지 않으면 브라우저에 표시되지 않는다.사이즈가 큰 데이터를 전송하는 경우에 데이터를 분할해서 조금씩 표시할 수 있습니다. 이렇게 엔티티 바디를 분할하는 기능을 청크 전송 코딩이라고 부른다. 청크 전송 코딩은 엔티티 바디를 청크(덩어리)로 분해한다. 이 엔티티 바디는 수신한 클라이언트 측에서 원래의 엔티티 바디로 디코딩한다.

최적의 콘텐츠를 돌려주는 콘텐츠 네고시에이션

 같은 콘텐츠이지만 여러 개의 페이지를 지닌 웹페이지가 있다. 예를 들면 내용은 같지만 영어, 한국어와같이 언어가 다른 페이지이다. 서로 다른 언어를 사용하는 브라우저가 같은 URI에 접근할 때 각각 영어, 한국어 웹페이지를 표시한다. 이 같은 구조를 콘텐츠 네고시에이션(content negotiation)이라고 한다. 클라이언트에 더욱 적합한 리소스를 제공하기 위한 구조이다.

 콘텐츠 네고시에이션 종류 :

1. 서버 구동형 네고시에이션 (Server-driven Negotiation) : 서버 측에서 리퀘스트 헤더 필드의 정보를 참고하여 자동으로 처리한다. 브라우저에서 보내는 정보를 기반으로 하기에, 정말로 클라이언트에게 적합한지 알 수 없다.
2. 에이전트 구동형 네고시에이션 (Agent-driven Negotiation) : 클라이언트 측에서 브라우저에 표시된 선택지를 수동으로 선택하여 처리한다. JS를 이용, OS 종류, 브라우저의 종류에 따라 웹 페이지가 자동으로 전환되는 경우에 해당한다.
3. 트랜스패런트 네고시에이션 (Transparent Negotiation) : 서버 구동형 + 에이전트 구동형. 서버와 클라이언트가 각각 처리한다.