HTTP概述

Web瀏覽器、伺服器和相關的Web應用程式都是通過HTTP相互通訊。HTTP是現代全球因特網中使用的公共語言。

HTTP-因特網的多媒體信使

每天都有數億JPEG圖片、HTML頁面、文字檔案、MPEG電影、WAV音訊檔案、java小程式和其他資源在因特網遊弋。HTTP可以從全世界的Web伺服器上將這些資訊迅速、便捷、可靠的傳輸到Web瀏覽器上。
HTTP使用的是可靠的資料傳輸協議，它能夠確保資料在傳輸過程中不會被損壞或者產生混亂。對開發人員來說，無需擔心HTTP通訊會在傳輸過程中被破壞、複製或者產生畸變。開發人員可以專注於程式特有細節的編寫，而不是考慮因特網中存在的一些缺陷和問題。

Web客戶端和伺服器

Web內容都是儲存在Web伺服器上。Web伺服器使用HTTP協議，因此還可以稱為HTTP伺服器。HTTP客戶端向伺服器發出請求，伺服器會在HTTP響應中回送所請求的資料。

最常見的HTTP客戶端就是瀏覽器。瀏覽器向伺服器請求HTTP物件，並將物件顯示在螢幕上。

媒體型別

因特網有很多的資料型別，HTTP給每種要通過Web傳輸的物件都打上MIME型別（MIME type）的資料格式標籤。最初設計MIME(Multipurpose Internet Mail Extension,多用途因特網郵件擴充套件)是為了解決不同電子郵件系統之家搬移報文時存在的問題。
Web伺服器會為所有的HTTP物件資料附一個MIME型別。當Web瀏覽器從伺服器取回一個物件時，會去檢視相關的MIME型別，看看它是否知道應該如何處理這個物件。大多數瀏覽器都可以處理上百種常見物件：顯示圖片、解析並格式化HTML檔案、播放音訊檔案、或者執行外部軟體來處理特殊格式資料。
MIME型別是一種文字標記，表示一種主要的物件型別和一個特定的子型別，中間由一條斜槓來分隔。
例如：HTML格式的文字文件 text/html型別來標記。

URI

每個Web伺服器都有一個名字，這樣客戶端就可以說明它們感興趣的資源是什麼。伺服器資源名被統一稱為統一資源識別符號（Uniform Resource Identifier，URI）。URI有兩種形式：分別是URL和URN。

• URL
  

  統一資源定位符（URL,Uniform Resource Locator）是資源識別符號最常見的形式。
  

大部分URL都遵循一種標準格式，這種格式包含三個部分。
1.URL的第一部分稱為方案（scheme），說明訪問資源所使用的協議型別。這部分通常是HTTP或者HTTPS（http://)。
2.第二部分給出了伺服器的因特網地址（www.joes-hardware.com）。
3.其餘部分指定了Web伺服器上的某個資源（比如，/specials/saw-blade.gif）。
現在幾乎所有的URI都是URL。

• URN

URI的第二種形式就是URN（統一資源名）。URN是作為特定內容的唯一名稱使用的，與目前的資源所在地無關。使用這些與>位置無關的URN，就可以將資源四處搬動。通過URN，還可以用同一個名字通過多種網路訪問協議來訪問資源。
URN仍然處於試驗階段，還未大範圍使用。除非特殊說明，否則這裡的都是用URL來指定URI。

事務

一個HTTP事務由一條請求命令和一個響應結果組成。這種通訊通過名為HTTP報文（HTTP message）的格式化資料塊進行。

• 方法

HTTP支援幾種幾種不同的請求命令，這些命令被稱為HTTP方法（HTTP method）。每條HTTP請求報文都包含一個方法。這個方法會告訴伺服器要執行什麼動作（獲取一個Web頁面、執行一個閘道器程式、刪除一個檔案等）。

常見的HTTP方法：

HTTP方法	描述
GET	從伺服器向客戶端傳送命名資源
PUT	將來自客戶端的資料儲存到一個命名的資源伺服器中
DELETE	從伺服器中刪除命名資源
POST	將客戶端資料傳送到一個伺服器閘道器應用程式
HEAD	僅傳送命名資源響應中的HTTP首部

- 狀態碼

每條HTTP響應報文返回時都會攜帶一個狀態碼。狀態碼是一個三位數字的程式碼，告知客戶端請求是否成功，或者是否需要採取其他動作。

常見的HTTP狀態碼：

HTTP狀態碼	描述
200	OK, 文件正確返回
302	Redirect（重定向）。到其他地方去獲取資源
404	Not Found（沒找到），無法找到這個資源

- Web頁面可以包含多個物件

應用程式完成一項任務時通常會發布多個HTTP事務。比如，Web瀏覽器會發布一系列的HTTP事務來獲取並顯示一個包含豐富圖片的Web頁面。瀏覽器會執行一個事務來獲取描述頁面佈局的HTML”框架“，然後釋出另外的HTTP事務來獲取每個嵌入式圖片、影象面板、Java小程式等。這些嵌入式資源甚至可能位於不同的伺服器。因此，一個Web頁面通常並不是單個資源，而是一組資源的集合。

報文

HTTP報文都是由一行行的簡單字串組成。HTTP報文都是純文字，不是二進位制程式碼。

從Web客戶端發往Web伺服器的HTTP報文稱為請求報文（request message）。從伺服器發往客戶端的報文稱為響應報文（reponse message），此外沒有其他型別的HTTP報文。請求報文和響應報文格式類似。
HTTP報文包括以下三部分：

• 起始行

報文的第一行就是起始行，在請求報文中用來說明要做些什麼，在響應報文中說明出現了什麼情況。

• 首部欄位

起始行後面有0個或者多個首部欄位。每個欄位都包含一個名字和一個值，為了便於解析，兩者之間用冒號（：）分隔。首部以一個空行結束。新增一個首部欄位和新增新行一樣簡單。

• 主體

空行之後就是可選的報文主體了，其中包含了所有型別的資料。請求主體中包括了要發給Web伺服器的資料，響應主體中裝載了要返回給客戶端的資料。起始行和首部都是文字形式且都是結構化的，而主體則不同，主體可以包含任意的二進位制資料（圖片、視訊、音訊、軟體程式）。當然，主體還可以包含文字。

連線

• TCP/IP

HTTP是個應用層協議。HTTP無需關心網路通訊的具體細節；它把聯網的細節都給了通用、可靠的因特網傳輸協議TCP/IP。
TCP提供了：
- 無差錯的資料傳輸。
- 按序傳輸（資料總是按照發送的順序到達）；
- 分段的資料流（可以在任意時刻以任意大小將資料傳送出去）。
因特網自身是基於TCP/IP的，它是全世界計算機網路常用的層次化分組交換網路協議集。TCP/IP 隱藏了各種網路和硬體的特點及弱點，使各種型別的計算機和網路都能夠進行可靠地通訊。
只要建立了TCP連線，客戶端和伺服器之間的報文交換就不會丟失、被破壞、也不會出現接收時亂序。HTTP協議位於TCP的上層。HTTP使用TCP來傳輸其報文資料。

• 連線、IP地址及埠號

在HTTP客戶端向伺服器傳送報文之前，需要用網際協議（Internet Prococol，IP）地址和埠號在客戶端和伺服器之間建立一條TCP/IP連線。
建立一條TCP連線的過程與給公司辦公室的某個人打電話的過程類似。首先，要撥打公司的電話號碼。這樣就能進入正確的機構了。其次，撥打要聯絡的那個人的分機號。
最初怎麼獲取伺服器的IP地址呢？當然是通過URL。
先看幾個URL:
http://207.200.83.29:80/index.html
http://www.netscape.com:80/index.html
http://www.netscape.com/index.html
第一個 URL 使用了機器的 IP 地址，207.200.83.29 以及埠.第二個 URL 沒有使用數字形式的 IP 地址，它使用的是文字形式的域名，或者稱為主機名（www.netscape.com） 。主機名就是 IP 地址比較人性化的別稱。可以通過一
種稱為域名服務（Domain Name Service，DNS）的機制方便地將主機名轉換為 IP地址，這樣所有問題就都解決了。
最後一個 URL 沒有埠號。HTTP 的 URL 中沒有埠號時，可以假設預設埠號是 80。有了 IP 地址和埠號，客戶端就可以很方便地通過 TCP/IP 進行通訊了。

• 連線、IP地址及埠號

在HTTP客戶端向伺服器傳送報文之前，需要用網際協議（Internet Prococol，IP）地址和埠號在客戶端和伺服器之間建立一條TCP/IP連線。
建立一條TCP連線的過程與給公司辦公室的某個人打電話的過程類似。首先，要撥打公司的電話號碼。這樣就能進入正確的機構了。其次，撥打要聯絡的那個人的分機號。
最初怎麼獲取伺服器的IP地址呢？當然是通過URL。
先看幾個URL:
http://207.200.83.29:80/index.html
http://www.netscape.com:80/index.html
http://www.netscape.com/index.html
第一個 URL 使用了機器的 IP 地址，207.200.83.29 以及埠.第二個 URL 沒有使用數字形式的 IP 地址，它使用的是文字形式的域名，或者稱為主機名（www.netscape.com） 。主機名就是 IP 地址比較人性化的別稱。可以通過一
種稱為域名服務（Domain Name Service，DNS）的機制方便地將主機名轉換為 IP地址，這樣所有問題就都解決了。
最後一個 URL 沒有埠號。HTTP 的 URL 中沒有埠號時，可以假設預設埠號是 80。有了 IP 地址和埠號，客戶端就可以很方便地通過 TCP/IP 進行通訊了。

步驟如下：

(a) 瀏覽器從 URL 中解析出伺服器的主機名；

(b) 瀏覽器將伺服器的主機名轉換成伺服器的 IP 地址；

(c) 瀏覽器將埠號（如果有的話）從 URL 中解析出來；

(d) 瀏覽器建立一條與 Web 伺服器的 TCP 連線；

(e) 瀏覽器向伺服器傳送一條 HTTP 請求報文；

(f) 伺服器向瀏覽器回送一條 HTTP 響應報文；

(g) 關閉連線，瀏覽器顯示文件。

• 使用Telnet例項
  

  Telnet程式可以將鍵盤連線到某個目標TCP埠，並將此TCP埠的輸出回送到顯示屏上。Telnet常用於遠端終端會話，但它幾乎可以連線所有的TCP伺服器，包括HTTP伺服器。
  可以通過Telnet程式直接與Web伺服器進行對話。通過Telnet可以開啟一條到某臺機器上某個埠的TCP連線，然後直接向埠輸入一些字元。Web伺服器會將Telnet程式作為一個Web客戶端來處理，然後回送給TCP連線的資料會顯示在螢幕上。
  實際例子：Telnet獲取URL http://www.joes-hardware.com:80/tools.html 所指向的文件
  

Telnet 會查詢主機名並開啟一條連線，連線到在 www.joes-hardware.com 的埠 80上監聽的 Web 伺服器。這條命令之後的三行內容是 Telnet 的輸出，告訴我們它已經建立了連線。
然後我們輸入最基本的請求命令 GET/tools.html HTTP/1.1 ，傳送一個提供了源端主機名的 Host 首部，後面跟上一個空行，請求從伺服器 www.joes-hardware.com 上獲取資源 tools.html。隨後，伺服器會以一個響應行、幾個響應首部、一個空行和最後面的 HTML 文件主體來應答。
要明確的是，Telnet 可以很好地模擬 HTTP 客戶端，但不能作為伺服器使用。而且對 Telnet 做指令碼自動化是很繁瑣乏味的。如果想要更靈活的工具，可以去看看 nc（netcat） 。通過 nc 可以很方便地操縱基於 UDP 和 TCP 的流量（包括 HTTP） ，還可以為其編寫指令碼。更多細節參見 http://www.bgw.org/tutorials/utilities/nc.php

協議版本

目前HTTP有幾個協議版本。

• HTTP/0.9

HTTP 的 1991 原型版本稱為 HTTP/0.9。這個協議有很多嚴重的設計缺陷，只應該用於與老客戶端的互動。HTTP/0.9 只支援 GET 方法，不支援多媒體內容的MIME 型別、各種 HTTP 首部，或者版本號。HTTP/0.9 定義的初衷是為了獲取簡單的 HTML 物件，它很快就被 HTTP/1.0 取代了。

• HTTP/1.0

1.0 是第一個得到廣泛使用的 HTTP 版本。HTTP/1.0 添加了版本號、各種 HTTP首部、一些額外的方法，以及對多媒體物件的處理。HTTP/1.0 使得包含生動圖片的 Web 頁面和互動式表格成為可能，而這些頁面和表格促使全球資訊網為人們廣泛地接受。這個規範從未得到良好地說明。在這個 HTTP 協議的商業演進和學術研究都在快速進行的時代，它集合了一系列的最佳實踐。

• HTTP/1.0+

在 20 世紀 90 年代中葉，很多流行的 Web 客戶端和伺服器都在飛快地向 HTTP中新增各種特性，以滿足快速擴張且在商業上十分成功的全球資訊網的需要。其中很多特性，包括持久的 keep-alive 連線、虛擬主機支援，以及代理連線支援都被加入到 HTTP 之中，併成為非官方的事實標準。這種非正式的 HTTP 擴充套件版本通常稱為 HTTP/1.0+。

• HTTP/1.1

HTTP/1.1 重點關注的是校正 HTTP 設計中的結構性缺陷，明確語義，引入重要的效能優化措施，並刪除一些不好的特性。HTTP/1.1 還包含了對 20 世紀 90 年代末正在發展中的更復雜的 Web 應用程式和部署方式的支援。HTTP/1.1 是當前使用的 HTTP 版本。

• HTTP-NG（又名 HTTP/2.0）

HTTP-NG 是 HTTP/1.1 後繼結構的原型建議，它重點關注的是效能的大幅優化，以及更強大的服務邏輯遠端執行框架。HTTP-NG 的研究工作終止於 1998 年，編寫本書時，還沒有任何要用此建議取代 HTTP/1.1 的推廣計劃。

Web結構元件

前面重點介紹了Web應用程式（Web客戶端和Web伺服器）是如何相互發送報文來實現基本事務處理的。因特網上還有一些其他的應用程式。下面一一介紹。

• 代理

代理位於客戶端和伺服器之間的HTTP中間實體。接收所有客戶端的 HTTP 請求，並將這些請求轉發給伺服器（可能會對請求進行修改之後轉發） 。對使用者來說，這些應用程式就是一個代理，代表使用者訪問伺服器。

出於安全考慮，通常會將代理作為轉發所有 Web 流量的可信任中間節點使用。代理還可以對請求和響應進行過濾。比如，在企業中對下載的應用程式進行病毒檢測，或者對小學生遮蔽一些成人才能看的內容。

• 快取
  

  Web 快取（Web cache）或代理快取（proxy cache）是一種特殊的 HTTP 代理伺服器，可以將經過代理傳送的常用文件複製儲存起來。下一個請求同一文件的客戶端就可以享受快取的私有副本所提供的服務了.
  

客戶端從附近的快取下載文件會比從遠端 Web 伺服器下載快得多。HTTP 定義了很多功能，使得快取更加高效，並規範了文件的新鮮度和快取內容的隱私性。

• 閘道器

閘道器（gateway）是一種特殊的伺服器，作為其他伺服器的中間實體使用。通常用於將 HTTP 流量轉換成其他的協議。閘道器接受請求時就好像自己是資源的源端伺服器一樣。客戶端可能並不知道自己正在與一個閘道器進行通訊。
例如，一個 HTTP/FTP 閘道器會通過 HTTP 請求接收對 FTP URI 的請求，但通過 FTP協議來獲取文件 。得到的文件會被封裝成一條 HTTP 報文，傳送給客戶端。第 8 章將探討閘道器。

• 隧道

隧道（tunnel）是建立起來之後，就會在兩條連線之間對原始資料進行盲轉發的HTTP 應用程式。HTTP 隧道通常用來在一條或多條 HTTP 連線上轉發非 HTTP 資料，轉發時不會窺探資料。
HTTP 隧道的一種常見用途是通過 HTTP 連線承載加密的安全套接字層（SSL，Secure Sockets Layer）流量，這樣 SSL 流量就可以穿過只允許 Web 流量通過的防火牆了。如圖所示，HTTP/SSL 隧道收到一條 HTTP 請求，要求建立一條到目的地址和埠的輸出連線，然後在 HTTP 通道上通過隧道傳輸加密的 SSL 流量，這樣就可以將其盲轉發到目的伺服器上去了。

• Agent代理

使用者 Agent 代理（或者簡稱為 Agent 代理）是代表使用者發起 HTTP 請求的客戶端程式。所有釋出 Web 請求的應用程式都是 HTTP Agent 代理。到目前為止，我們只提到過一種 HTTP Agent 代理：Web 瀏覽器，但使用者 Agent 代理還有很多其他型別。用fiddler抓包找頭部資訊會發現類似User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/49.0.2623.112 Safari/537.36
比如，有些自己會在 Web 上閒逛的自動使用者 Agent 代理，可以在無人監視的情況下發布 HTTP 事務並獲取內容。這些自動代理的名字通常都很生動，比如“網路蜘蛛”（spiders）或者“Web 機器人” （Web robots） 。網路蜘蛛會在 Web 上閒逛，蒐集資訊以構建有效的 Web 內容檔案，比如一個搜尋引擎的資料庫或者為比較購物機器人生成的產品目錄。

URL和資源

因特網資源

URL是瀏覽器尋找資訊所需的資源位置。URI是一類更通用的資源識別符號，URL是URI的一個子集。URI包括URL和URN。

URL語法

<scheme>://<user>:<password>@<host>:<port>/<path>;<params>?<query>#<frag>

• scheme
  訪問伺服器以獲取資源時要使用的協議 預設值 無
• user
  一些方案訪問資源時需要的使用者名稱 預設值 匿名
• password
  使用者名稱後面可能要包含密碼,中間由冒號分隔 預設值
• host
  資源宿主伺服器的主機名或點分IP地址 預設值 無
• port
  資源宿主伺服器正在監聽的埠號,很多方案都有預設埠號(HTTP預設埠號為80) 預設值 每個方案特有
• path
  伺服器上資源的本地名,由一個”/”將其與前面的URL元件分隔開來.路徑元件的語法與伺服器和方案有關 預設值 無
• params
  一些方案會用這個元件指定輸入引數. 引數為名/值對. URL中可以包含多個引數欄位,它們相互以及與路徑的其餘部分之間用分號(;)分隔 預設值 無
• query
  一些方案會用這個元件傳遞引數以啟用應用程式.查詢元件的內容沒有通用格式.用符號”?”將其與URL的其餘部分分隔開來 預設值 無
• frag
  一小片或一部分資源的名字.引用物件時,不會將frag欄位傳送給伺服器。這個欄位是在客戶端內部使用的.通過字元”#”將其與URL其餘部分分隔開來 預設值 無

http://www.joes-hardware.com/hammers;sale=false/index.html;graphic=ture
這個例子就有兩個路徑段，hammers和index.html。hammers路徑段的引數是sale，值為false。index.html段有引數graphics，值為true。
http://www.joes-hardware.com/inventory-check.cgi?item=12731
問號右邊的內容稱為查詢元件。URL的查詢元件和標誌閘道器資源的URL路徑元件一起被髮送給閘道器資源。基本上可以將閘道器當作訪問其他應用程式的訪問點。
HTTP伺服器只處理整個物件，而不是物件的片段，客戶端不能將片段傳送給伺服器，瀏覽器獲得整個資源後，會根據片段來顯示你感興趣的內容。

TCP/IP的三次握手，四次分手

首先我們先來了解TCP報文段

重要的標誌我在圖中也有標記，重點了解標誌位
ACK：確認序號有效
RST：重置連線
SYN：發起了一個新連線
FIN：釋放一個連線

三次握手的過程（客戶端我們用A表示，伺服器端用B表示）

前提：A主動開啟，B被動開啟

1. 在建立連線之前，B先建立TCB（傳輸控制塊），準備接受客戶程序的連線請求，處於LISTEN（監聽）狀態
2. A首先建立TCB，然後向B發出連線請求，SYN置1，同時選擇初始序號seq=x，進入SYN-SEND（同步已傳送）狀態
3. B收到連線請求後向A傳送確認，SYN置1，ACK置1，同時產生一個確認序號ack=x+1。同時隨機選擇初始序號seq=y，進入SYN-RCVD（同步收到）狀態
4. A收到確認連線請求後，ACK置1，確認號ack=y+1，seq=x+1，進入到ESTABLISHED（已建立連線）狀態。向B發出確認連線，最後B也進入到ESTABLISHED（已建立連線）狀態。

簡單來說，就是
1. 建立連線時，客戶端傳送SYN包（SYN=i）到伺服器，並進入到SYN-SEND狀態，等待伺服器確認
2. 伺服器收到SYN包，必須確認客戶的SYN（ack=i+1）,同時自己也傳送一個SYN包（SYN=k）,即SYN+ACK包，此時伺服器進入SYN-RECV狀態
3. 客戶端收到伺服器的SYN+ACK包，向伺服器傳送確認報ACK（ack=k+1）,此包傳送完畢，客戶端和伺服器進入ESTABLISHED狀態，完成三次握手

在此穿插一個知識點就是SYN攻擊，那麼什麼是SYN攻擊？發生的條件是什麼？怎麼避免？
在三次握手過程中，Server傳送SYN-ACK之後，收到Client的ACK之前的TCP連線稱為半連線（half-open connect），此時Server處於SYN_RCVD狀態，當收到ACK後，Server轉入ESTABLISHED狀態。SYN攻擊就是 Client在短時間內偽造大量不存在的IP地址，並向Server不斷地傳送SYN包，Server回覆確認包，並等待Client的確認，由於源地址 是不存在的，因此，Server需要不斷重發直至超時，這些偽造的SYN包將產時間佔用未連線佇列，導致正常的SYN請求因為佇列滿而被丟棄，從而引起網 絡堵塞甚至系統癱瘓。SYN攻擊時一種典型的DDOS攻擊，檢測SYN攻擊的方式非常簡單，即當Server上有大量半連線狀態且源IP地址是隨機的，則可以斷定遭到SYN攻擊了，使用如下命令可以讓之現行：
#netstat -nap | grep SYN_RECV

四次分手的過程（客戶端我們用A表示，伺服器端用B表示）

由於TCP連線時是全雙工的，因此每個方向都必須單獨進行關閉。這一原則是當一方完成資料傳送任務後，傳送一個FIN來終止這一方向的連結。收到一個FIN只是意味著這一方向上沒有資料流動，既不會在收到資料，但是在這個TCP連線上仍然能夠傳送資料，知道這一方向也傳送了FIN，首先進行關閉的一方將執行主動關閉，而另一方則執行被動關閉。

前提：A主動關閉，B被動關閉

有人可能會問，為什麼連線的時候是三次握手，而斷開連線的時候需要四次揮手？
這是因為服務端在LISTEN狀態下，收到建立連線請求的SYN報文後，把ACK和SYN放在一個報文裡傳送給客戶端。而關閉連線時，當收到對方的FIN 報文時，僅僅表示對方不再發送資料了但是還能接收資料，己方也未必全部資料都發送給對方了，所以己方可以立即close，也可以傳送一些資料給對方後，再 傳送FIN報文給對方來表示同意現在關閉連線，因此，己方ACK和FIN一般都會分開發送。

1. A傳送一個FIN，用來關閉A到B的資料傳送，A進入FIN_WAIT_1狀態。
2. B收到FIN後，傳送一個ACK給A，確認序號為收到序號+1（與SYN相同，一個FIN佔用一個序號），B進入CLOSE_WAIT狀態。
3. B傳送一個FIN，用來關閉B到A的資料傳送，B進入LAST_ACK狀態。
4. A收到FIN後，A進入TIME_WAIT狀態，接著傳送一個ACK給B，確認序號為收到序號+1，B進入CLOSED狀態，完成四次揮手。

簡單來說就是
1. 客戶端A傳送一個FIN，用來關閉客戶A到伺服器B的資料傳送（報文段4）。
2. 伺服器B收到這個FIN，它發回一個ACK，確認序號為收到的序號加1（報文段5）。和SYN一樣，一個FIN將佔用一個序號。
3. 伺服器B關閉與客戶端A的連線，傳送一個FIN給客戶端A（報文段6）。
4. 客戶端A發回ACK報文確認，並將確認序號設定為收到序號加1（報文段7）。

A在進入到TIME-WAIT狀態後，並不會馬上釋放TCP，必須經過時間等待計時器設定的時間2MSL（最長報文段壽命），A才進入到CLOSED狀態。為什麼？
為了保證A傳送的最後一個ACK報文段能夠到達B
防止“已失效的連線請求報文段”出現在本連線中

OK~是不是很難懂的感覺？那我們來說的“人性化點的”吧

三次握手流程
1. 客戶端發個請求“開門吶，我要進來”給伺服器
2. 伺服器發個“進來吧，我去給你開門”給客戶端
3. 客戶端有很客氣的發個“謝謝，我要進來了”給伺服器

四次揮手流程
1. 客戶端發個“時間不早了，我要走了”給伺服器，等伺服器起身送他
2. 伺服器聽到了，發個“我知道了，那我送你出門吧”給客戶端，等客戶端走
3. 伺服器把門關上後，發個“我關門了”給客戶端，然後等客戶端走（尼瑪~矯情啊）
4. 客戶端發個“我知道了，我走了”，之後自己就走了