從前端發起請求到後臺的整個過程，是一個面試中經常遇到的問題。大概的流程想必有一點基礎的人都明白，但是要細說，卻未必能一一道出來，曾經老師教過的知識也都差不多忘乾淨了。所以，我上網找了點資料，加上自己的理解，做個記錄。

**********************************************************  華麗的分割線 ******************************************************************

一、HTTP是什麼

        http（HyperText Transfer Protocol），超文字傳輸協議，是網際網路上應用最廣泛的一種網路協議，所有www檔案都必須遵守的一個標準，是以 ASCII 碼傳輸，建立在 TCP/IP 協議之上的應用層規範。說白了，就是大家都約好互相之間按照一種固定的規則來進行通訊。

        http也可以說成是一種客戶端和應答伺服器端請求和應答的標準（TCP）。通過使用瀏覽器或其他工具（如google的Postman），客戶端發起一個到應答伺服器上指定埠（如Tomcat的8080或jmx的1099等）的http請求，或者反過來，伺服器給客戶端傳送一個迴應。在客戶端和應答伺服器端可能存在多箇中間層，比如代理、閘道器或者隧道。

二、HTTP請求報文

        http請求報文是指客戶端到伺服器端的訊息，客戶端通過傳送http請求向伺服器請求對資源的訪問。包括三個部分：請求行、請求頭部、請求資料。請求方法有 OPTIONS、GET、HEAD、POST、PUT、DELETE、TRACE、CONNECT 這幾種。

       1.請求行：包含請求方法、uri和協議的版本，用空格分隔，例如：GET/sample.jsp HTTP/1.1

        2.請求頭部：包含有關客戶端環境及請求正文的資訊，如請求正文長度、瀏覽器所用編碼格式等，例如;

Accept:image/gif.image/jpeg.*/*

Accept-Language:zh-cn

Connection:Keep-Alive

Host:localhost

User-Agent:Mozila/4.0(compatible:MSIE5.01:Windows NT5.0)

Accept-Encoding:gzip,deflate

        3.請求資料：即客戶端傳送給伺服器的內容，可為空（GET請求就沒有請求資料），例如：username=jinqiao&password=1234

PS：1.請求頭部和請求資料之間必須有空行，用以區分。

         2.最常用的請求頭部是Content-Type（請求編碼方式）和Content-Length（請求資料長度），例如：

Content-Type: application/x-www-form-urlencoded 

Content-Length: 35 

三、HTTP應答報文

        http應答報文是指伺服器迴應http請求，傳送給客戶端的訊息。也包括三個部分：狀態行、響應頭部、響應資料。

    1 狀態行：協議版本、狀態碼、簡要描述，例如：HTTP/1.1 200 OK

    2 響應頭部：必須指明Content-Type，其他可選，例如：Content-Type: text/plain

    3 響應資料：即伺服器迴應客戶端的內容。

PS：常見狀態碼

1xx：指示資訊--表示請求已接收，繼續處理。 2xx：成功--表示請求已被成功接收、理解、接受。 3xx：重定向--要完成請求必須進行更進一步的操作。 4xx：客戶端錯誤--請求有語法錯誤或請求無法實現。 5xx：伺服器端錯誤--伺服器未能實現合法的請求。

四、HTTP請求與響應步驟

        http請求和響應，說白了就是計算機之間的問答對話。http請求是提問者，http響應是回答者。詳細步驟如下圖所示。

    1 建立連線

        先解析DNS，把localhost變成ip（127.0.0.1），然後根據127.0.0.1和埠號8080（沒有埠號則使用預設的埠）建立socket。也可以理解為通過“三次握手”建立TCP連線，確定通訊正常。

    2 傳送請求命令

        socket建立好之後，客戶端開始向web伺服器傳送請求命令（GET/POST等）。

    3 傳送請求頭（和請求正文如果有）

       客戶端先發送與自身相關的資訊，再發送空行表示請求頭髮送完畢，如果是post則繼續傳送請求正文。

    4 回傳狀態行

        應答第一步，傳送協議版本和狀態碼（200、503、404等）

    5 回傳應答頭

        應答第二步，先發送自身相關資訊、Content-Type(必須)及被請求的文件，在傳送空行寶石應答頭髮送完畢。

    6 回傳應答正文

        應答第三步，根據應答頭的Content-Type指定的格式傳送應答正文。

    7 關閉連線

       一次‘會話’完成，如果設定了Connection：keep-alive則TCP連線不關閉，否則關閉連線。

五、TCP/IP協議

TCP/IP協議模型（Transmission Control Protocol/Internet Protocol），包含了一系列構成網際網路基礎的網路協議，是Internet的核心協議，通過20多年的發展已日漸成熟，並被廣泛應用於區域網和廣域網中，目前已成為事實上的國際標準。TCP/IP協議簇是一組不同層次上的多個協議的組合，通常被認為是一個四層協議系統，與OSI的七層模型相對應。

HTTP協議就是基於TCP/IP協議模型來傳輸資訊的。

1 鏈路層         也稱作資料鏈路層或網路介面層（在第一個圖中為網路介面層和硬體層），通常包括作業系統中的裝置驅動程式和計算機中對應的網路介面卡。它們一起處理與電纜（或其他任何傳輸媒介）的物理介面細節。ARP（地址解析協議）和RARP（逆地址解析協議）是某些網路介面（如乙太網和令牌環網）使用的特殊協議，用來轉換IP層和網路介面層使用的地址。

2 網路層        也稱作網際網路層（在第一個圖中為網際層），處理分組在網路中的活動，例如分組的選路。在TCP/IP協議族中，網路層協議包括IP協議（網際協議），ICMP協議（Internet網際網路控制報文協議），以及IGMP協議（Internet組管理協議）。       IP是一種網路層協議，提供的是一種不可靠的服務，它只是儘可能快地把分組從源結點送到目的結點，但是並不提供任何可靠性保證。同時被TCP和UDP使用。TCP和UDP的每組資料都通過端系統和每個中間路由器中的IP層在網際網路中進行傳輸。       ICMP是IP協議的附屬協議。IP層用它來與其他主機或路由器交換錯誤報文和其他重要資訊。IGMP是Internet組管理協議。它用來把一個UDP資料報多播到多個主機。

3 傳輸層       主要為兩臺主機上的應用程式提供端到端的通訊。在TCP/IP協議族中，有兩個互不相同的傳輸協議：TCP（傳輸控制協議）和UDP（使用者資料報協議）。       TCP為兩臺主機提供高可靠性的資料通訊。它所做的工作包括把應用程式交給它的資料分成合適的小塊交給下面的網路層，確認接收到的分組，設定傳送最後確認分組的超時時鐘等。由於運輸層提供了高可靠性的端到端的通訊，因此應用層可以忽略所有這些細節。為了提供可靠的服務，TCP採用了超時重傳、傳送和接收端到端的確認分組等機制。       UDP則為應用層提供一種非常簡單的服務。它只是把稱作資料報的分組從一臺主機發送到另一臺主機，但並不保證該資料報能到達另一端。一個數據報是指從傳送方傳輸到接收方的一個資訊單元（例如，傳送方指定的一定位元組數的資訊）。UDP協議任何必需的可靠性必須由應用層來提供。

4  應用層       應用層決定了向用戶提供應用服務時通訊的活動。TCP/IP 協議族內預存了各類通用的應用服務。包括 HTTP，FTP（File Transfer Protocol，檔案傳輸協議），DNS（Domain Name System，域名系統）服務。

         當應用程式用TCP傳送資料時，資料被送入協議棧中，然後逐個通過每一層直到被當作一串位元流送入網路。其中每一層對收到的資料都要增加一些首部資訊（有時還要增加尾部資訊），該過程如圖所示。

       當目的主機收到一個乙太網資料幀時，資料就開始從協議棧中由底向上升，同時去掉各層協議加上的報文首部。每層協議盒都要去檢查報文首部中的協議標識，以確定接收資料的上層協議。這個過程稱作分用（Demultiplexing）。協議是通過目的埠號、源I P地址和源埠號進行解包的。

      通過以上步驟我們從TCP/IP模型的角度來理解了一次HTTP請求與響應的過程。下面這張圖更清楚明白：

六、TCP三次握手

第一次握手

        建立連線。客戶端傳送連線請求報文段，將SYN位置為1，Sequence Number為x；然後，客戶端進入SYN_SEND狀態，等待伺服器的確認；

第二次握手

        伺服器收到SYN報文段。伺服器收到客戶端的SYN報文段，需要對這個SYN報文段進行確認，設定Acknowledgment Number為x+1(Sequence Number+1)；同時，自己自己還要傳送SYN請求資訊，將SYN位置為1，Sequence Number為y；伺服器端將上述所有資訊放到一個報文段（即SYN+ACK報文段）中，一併傳送給客戶端，此時伺服器進入SYN_RECV狀態；

第三次握手

       客戶端收到伺服器的SYN+ACK報文段。然後將Acknowledgment Number設定為y+1，向伺服器傳送ACK報文段，這個報文段傳送完畢以後，客戶端和伺服器端都進入ESTABLISHED狀態，完成TCP三次握手。

為什麼要三次握手

為了防止已失效的連線請求報文段突然又傳送到了服務端，因而產生錯誤。

具體例子：“已失效的連線請求報文段”的產生在這樣一種情況下：client發出的第一個連線請求報文段並沒有丟失，而是在某個網路結點長時間的滯留了，以致延誤到連線釋放以後的某個時間才到達server。本來這是一個早已失效的報文段。但server收到此失效的連線請求報文段後，就誤認為是client再次發出的一個新的連線請求。於是就向client發出確認報文段，同意建立連線。假設不採用“三次握手”，那麼只要server發出確認，新的連線就建立了。由於現在client並沒有發出建立連線的請求，因此不會理睬server的確認，也不會向server傳送資料。但server卻以為新的運輸連線已經建立，並一直等待client發來資料。這樣，server的很多資源就白白浪費掉了。採用“三次握手”的辦法可以防止上述現象發生。例如剛才那種情況，client不會向server的確認發出確認。server由於收不到確認，就知道client並沒有要求建立連線。”

七、四次揮手

第一次分手

       主機1（可以使客戶端，也可以是伺服器端），設定Sequence Number，向主機2傳送一個FIN報文段；此時，主機1進入FIN_WAIT_1狀態；這表示主機1沒有資料要傳送給主機2了；

第二次分手

       主機2收到了主機1傳送的FIN報文段，向主機1回一個ACK報文段，Acknowledgment Number為Sequence Number加1；主機1進入FIN_WAIT_2狀態；主機2告訴主機1，我“同意”你的關閉請求；

第三次分手

       主機2向主機1傳送FIN報文段，請求關閉連線，同時主機2進入LAST_ACK狀態；

第四次分手

       主機1收到主機2傳送的FIN報文段，向主機2傳送ACK報文段，然後主機1進入TIME_WAIT狀態；主機2收到主機1的ACK報文段以後，就關閉連線；此時，主機1等待2MSL後依然沒有收到回覆，則證明Server端已正常關閉，那好，主機1也可以關閉連線了。

為什麼要四次分手        TCP協議是一種面向連線的、可靠的、基於位元組流的運輸層通訊協議。TCP是全雙工模式，這就意味著，當主機1發出FIN報文段時，只是表示主機1已經沒有資料要傳送了，主機1告訴主機2，它的資料已經全部發送完畢了；但是，這個時候主機1還是可以接受來自主機2的資料；當主機2返回ACK報文段時，表示它已經知道主機1沒有資料傳送了，但是主機2還是可以傳送資料到主機1的；當主機2也傳送了FIN報文段時，這個時候就表示主機2也沒有資料要傳送了，就會告訴主機1，我也沒有資料要傳送了，之後彼此就會愉快的中斷這次TCP連線。

參考資料：（向前輩致敬）

http://www.jianshu.com/p/c1d6a294d3c0   一次完整的HTTP請求與響應涉及了哪些知識？

http://www.cnblogs.com/mengdd/archive/2013/05/26/3099776.html    HTTP基礎：URL格式、 HTTP請求、響應、訊息

百度百科等 ---------------------  作者：涓涓細劉  來源：CSDN  原文：https://blog.csdn.net/qq_33616529/article/details/78288883  版權宣告：本文為博主原創文章，轉載請附上博文連結！