commit

network/http/HTTP-basic.md → network/그림으로배우는_HTTP.md

@@ -1,6 +1,11 @@
-# 네트워크의 기본은 TCP/IP
+> 해당 글은 [그림으로 배우는 HTTP & Network](http://www.yes24.com/Product/Goods/15894097)를 보고 정리한 내용 입니다.
 
-## 계층으로 관리하는 TCP/IP
+
+# 1장 웹과 네트워크의 기본에 대해 알아보자
+
+## 네트워크의 기본은 TCP/IP
+
+### 계층으로 관리하는 TCP/IP
 
 * TCIP/IP에서 중요한 개념 중 하나가 계층입니다. TCIP/IP는 애플리케이션 계층, 전송 계층, 네트워크 계층, 링크 계층 이렇게 4 계츠으로 나뉘어 있습니다.
 * TCIP/IP가 계층화된 것은 메리트가 있기 때문입니다. 예를 들면 인터넷이 하나의 프로토콜로 되어 있다면 어디선가 사양이 변경되었을 때 전체를 바꾸지 않으면 안되지만, 계층화되어 있으면 사양이 변경된 해당 계층만 바꾸면 됩니다. 각 계층은 계층이 연결되어 있는 부분만 결정되어 있어, 각 계층의 내부는 자유롭게 설계할 수 있습니다.
@@ -9,12 +14,12 @@
 
 ![](/assets/tcp-4later.png)
 
-| 계층 | 계층명        | 주요 관심사                             |
-| ----- | --------- | ---------------------------------- |
-| 4     | 애플리케이션 계층 | 애플리케이션 사용하는 통신의 움직임 결정             |
-| 3     | 전송 계층     | 노드 간의 연결을 제어, 데이터를 전송의 신뢰성을 담당     |
-| 2     | 네트워크 계층   | 통신 노드 간의 IP패킷을 전송하는 기능과 라우팅 기능을 담당 |
-| 1     | 링크 계층     | 하드웨어 신호를 읽는 기능 담당                  |
+| 계층  | 계층명       | 주요 관심사                             |
+| --- | --------- | ---------------------------------- |
+| 4   | 애플리케이션 계층 | 애플리케이션 사용하는 통신의 움직임 결정             |
+| 3   | 전송 계층     | 노드 간의 연결을 제어, 데이터를 전송의 신뢰성을 담당     |
+| 2   | 네트워크 계층   | 통신 노드 간의 IP패킷을 전송하는 기능과 라우팅 기능을 담당 |
+| 1   | 링크 계층     | 하드웨어 신호를 읽는 기능 담당                  |
 
 
 ### 애플리케이션 계층
@@ -78,23 +83,84 @@ TCP는 계층으로 말하자면 전송 계층에 해당하는데, 신뢰성 있
 * 마지막으로 송신측이 `ACK` 플래그를 보내 패킷 교환이 완료되었을을 전달합니다.
 * 이 과정에서 어디선가 통신이 도중에 끊어지면 TCP는 그와 동시에 같은 수순으로 패킷을 재전송합니다.
 
-
-# 간단한 프로토콜 HTTP
+# 재 2장 간단한 프로토콜 HTTP
 * HTTP는 상태를 계속 유지하지 않은 스테이트리스 프로토콜입니다. 
 * HTTP 프로토콜 독자적으로, 리퀘스트와 리스폰스를 교환하는 동안에 상태를 관리하지 않습니다. 결국 **HTTP 프로토콜 레벨에서 이전에 보냈던 리퀘스트나 이미 되돌려준 리스폰스에 대해서는 전혀 기억하지 않습니다.**
 * HTTP에서는 새로운 리퀘스트가 보내질 때 마다 새로운 리스폰스가 생성됩니다. 프로토콜로서는 과거의 리퀘스트나 리스폰스 정보를 전혀 가지고 있지 않습니다.
 * **HTTP/1.1은 상태를 유지하지 않은 프로토콜입니다. 그래서 상태를 계속 유지하고 싶은 욕구에 부응하기 위해서 쿠키라는 기술이 도입되었습니다.**
 
+## HTTP는 상태를 유지하지 않는 프로토콜
+
+**HTTP는 상태를 계속 유지하지 않는 스테이트레스(stateless) 프로토콜입니다.** HTTP 프로토콜 독자적으로, 리퀘스트 리스폰스를 교환하는 동안에 상태(status)를 관리하지 않습니다. 결국 HTTP 프로토콜 레벨에는 이전에 보냈던 리퀘스트나 이미 돌러준 리스펀스에 대해서는 전혀 기억하지 않습니다.
+
+이는 많은 데이터를 매우 빠르고 확실하게 처리하는 범위성을 확보하기 위해서 이와 같이 간단하게 설계되어 있는 것입니다. 하지만 웹이 진화함에 따라서 상태를 관리해야할 필요성이 증가되었고, 그래서 **상태를 계속 유지하고 싶은 요구에 부응하기 위해서 쿠키라는 기술이 도입되었습니다.**
+
+## 서버에 임무를 부여하는 HTTP 메서드
+
+### Options: 제공하고 있는 메서드의 문의
+Options 메서드는 리퀘스트 URI로 지정한 리소스가 제공하고 있는 메소드를 조사하기 위해서 사용됩니다.
+
+| 구분       | 설명                                                    |
+| -------- | ----------------------------------------------------- |
+| Request  | OPTIOPNS* HTTP /1.1 <br> Host: www.harck.jp           |
+| Response | HTTP /1.1 200 OK <br> Allow: GET, POST, HEAD, OPTIONS |
+
+### Trace: 경로 조사
+TRACE 메서드는 Web 서버에서 접속해서 **자신에게 통신을 되돌려받는 루프백(Loop back)을 발생 시킵니다.**
+
+리퀘스트를 보낼떄 `Max-Forwards` 라는 해더 필드에 수치를 포함시켜 서버를 통과할 때 마다 그 수치를 줄여갑니다. 수치가 0이 되는 곳을 끝으로, 리퀘스트를 마지막으로 수신한 곳에서 상태 코드 200 OK 리스폰스를 돠돌려 줍니다.
+
+클라이언트는 TRACE 메서드를 사용함으로써, 리퀘스트를 보낸 곳에 어떤 리퀘스트가 가공되어 있는지를 등을 조사할 수 있습니다.
+
+이것은 프록시 등을 중계하여 오리진 서버에 접소갛ㄹ 때 그 동작을 확인 하기 위해서 사용되고 있습니다. 다만, TRACE 메서드는 거의 사용되지 않는데다 크로스 사이트 트레이싱(XST)과 같은 공격을 일으키는 보안 상의 문제도 있기 떄문에 보통은 사용되고 있지 않습니다.
+
 ## 지속 연결로 접속량을 절약
+![](../assets/http-connection-flow.jpg)
+
+HTTP 초기 버전에서는 **HTTP 통신을 한 번 할 때마다 TCP에 의해 연결과 종료**를 할 필요가 있었습니다. 하지만 다량의 이미지를 포함한 문서 등이 늘어 남아 따라서 리퀘스트를 보낼 떄마다 매번 TCP 연결과 종료를 하게 되는 쓸모 없는 일이 발생되어 통신량이 늘어나게 됩니다.
+
 
 ### 지속 연결
+![](../assets/http-connection-flow-2.jpg)
+
 HTTP/1.1와 HTTP/1.0에서는 TCP 연결 문제를 해결하기 위해서 지속 연결이라는 방법을 고안하였습니다. 지속 연결의 특징은 어느 한 쪽이 명시적으로 연결을 종료하지 않은 이상 TCP 연결을 계속 유지합니다. **지속 연결은 1회의 TCP 컨넥션 연결로 리퀘스트와 리스폰스 교환을 여려 번 한다.**
 
+지속 연결을 하는 이점은 TCP 컨넥션의 연결과 종료를 반복되는 오버헤드를 줄여주기 때문에 서버에 대한 부하가 경감됩니다.
+
 ### 파이프라인화
+![](../assets/http-connection-pipe.jpg)
+
 지속 연결은 여려 리퀘스트를 보낼 수 있도록 파이프라인화를 가능하게 합니다. 파이프라인화에 의해서 이전에는 리퀘스트 송신 후에 리스폰스를 수신할 때까지 기다린 뒤에 리퀘스트를 발행하던 것들을 리스폰스를 기다리지 않고 다음 리퀘스트를 보낼 수 있습니다.
 
-### 쿠키를 사용한 상태관리
-쿠키는 리퀘스트와 리스폰에 쿠키 정보를 추가해서 클라이언트의 상태를 파악하기 위한 시스템입니다. 쿠키는 서버에서 리스폰스로 보내진 Set-Cookie라는 헤더 필드에 의해 쿠키를 클라이언트에 보존하게 됩니다. 다음 번에 클라이언트가 같은 서버로 리퀘스트를 보낼 때, 자동적으로 쿠키 값을 넣어서 송신합니다. 서버는 클라이언트가 보내온 쿠키를 확인해 어느 클라이언트가 접속 했는지 체크하고 서버 상의 기록을 확인해 이전 상태를 알 수 있습니다.
+## 쿠키를 사용한 상태관리
+
+HTTP 프로토콜은 스테이트리스 프로토콜이기 때문에, 과거에 교환했던 리퀘스트와 리스폰스 상태를 관리하지 않습니다. 결국, 과거 상태를 근거로 현재 리퀘스트를 처리한다는 것은 불가능 합니다. **물론 스테이트리스 프로토콜 이점도 있습니다. 상태를 유지하지 않는 다는 점에서 서버의 CPU나 메모리 같은 리소스의 소비를 억제할 수 있습니다.**
+
+![](../assets/http-cookie.jpg)
+
+
+스테이트리스 프로토콜이라는 특징은 남겨준 채, 이와 같은 문제 해결하기 위해 쿠키라는 시스템이 도입되었습니다. **쿠키는 리퀘스트와 리스폰에 쿠키 정보를 추가해서 클라이언트의 상태를 파악하기 위한 시스템입니다.** 
+
+쿠키는 서버에서 리스폰스로 보내진 Set-Cookie라는 헤더 필드에 의해 쿠키를 클라이언트에 보존하게 됩니다. 다음 번에 클라이언트가 같은 서버로 리퀘스트를 보낼 때, 자동적으로 쿠키 값을 넣어서 송신합니다. 서버는 클라이언트가 보내온 쿠키를 확인해 어느 클라이언트가 접속 했는지 체크하고 서버 상의 기록을 확인해 이전 상태를 알 수 있습니다.
+
+```
+1. Request(쿠키를 가지고 있지 않은 상태)
+GET /reader/ HTTP 1.1
+Host www.xxxx.com
+*헤더 필드에 쿠키는 없다
+
+2. Response (서버가 쿠키를 발행)
+HTTP /1.1 200 OK
+Data: Thu 12 Jul 2012 07:00:00 GMT
+<Set-Cooke: sid=102030203; path=/;expires=Wed, => 10-Oct-12 07:12:00 GTM
+Content-Type: text/plain; charset=UTF-8
+
+3. Request
+GET /image/ HTTP /1.1
+Host: www.xxxx.com
+Cooke: sid=102030203
+```
+
 
 # HTTP 정보는 HTTP 메시지에 있다.