域名解析 --> 發起TCP的3次握手 --> 建立TCP連線後發起http請求 --> 伺服器響應http請求，瀏覽器得到html程式碼 --> 瀏覽器解析html程式碼，並請求html程式碼中的資源（如js、css、圖片等） --> 瀏覽器對頁面進行渲染呈現給使用者

如題，一個完整的HTTP過程是怎樣的？

一個完整的HTTP過程包括建立連線、資料傳輸、斷開連線等七個步驟。

下面喲喲來詳細介紹一下每一步：

1、TCP建立連線

HTTP協議是基於TCP協議來實現的，因此首先就是要透過TCP三次握手與伺服器端建立連線，一般HTTP預設的埠號為80；

2、瀏覽器傳送請求命令

在與伺服器建立連線後，Web瀏覽器會想伺服器傳送請求命令

3、瀏覽器傳送請求頭訊息

在瀏覽器傳送請求命令後，還會發送一些其它資訊，最後以一行空白內容告知伺服器已經完成頭資訊的傳送；

4、伺服器應答

在收到瀏覽器傳送的請求後，伺服器會對其進行迴應，應答的第一部分是協議的版本號和應答狀態碼；

5、伺服器迴應頭資訊

與瀏覽器端同理，伺服器端也會將自身的資訊傳送一份至瀏覽器；

6、伺服器傳送資料

在完成所有應答後，會以Content-Type應答頭資訊所描述的格式傳送使用者所需求的資料資訊；

7、斷開TCP連線

在完成此次資料通訊後，伺服器會透過TCP四次揮手主動斷開連線。但若此次連線為長連線，那麼瀏覽器或伺服器的頭資訊會加入keep-alive的資訊，會保持此連線狀態，在有其它資料傳送時，可以節省建立連線的時間；

Http請求的一次詳解:

客戶端輸入URL

客戶端檢測快取:

有快取且較新，客戶端直接讀取本地快取進行資源展示；

有快取但是不新，準備http請求包,傳送至服務端進行快取校驗；

備註:http1.0中Expire、http1.1中是Cache-Control根據發起http請求:

請求報文包含:a) 請求行用來說明請求型別(get\post\delete等)、要訪問的資源(URI)以及使用的HTTP版本(1.0還是1.1)b) 首部（header）HOST將指出請求的目的地；User-Agent由瀏覽器來定義,自動傳送；Connection:通常設定為keep-Alive, 長連線；其他首部包括等。c) 空行d) 請求實體

3. 提取請求首部HOST透過DNS域名解析獲取服務IP(DNS快取\遞迴等)

4. 透過IP與預設埠建立TCP連線,進行http請求報文資料傳送,其中重點就三次握手進行描述:

客戶端向服務端傳送syn=1，seq=client請求的ID;服務端向客戶端傳送syn=1,seq=服務端請求的ID,ack=客戶端請求的ID+1;客戶端向服務端傳送syn=0,seq=客戶端請求的ID+1,ack=服務端請求的ID+1,data\data…

5. 服務端程式接受請求，定向到請求路徑處理請求：

伺服器對請求報文進行解析，並獲取請求的資源及請求方法等相關資訊，根據方法，資源，首部和可選的主體部分對請求進行處理

元資料：請求報文首部 <method> <URL> <VERSION> HEADERS格式name:value <request body> 示例： Host: www.chuyuni.cn 請求的主機名稱 Server: Apache/2.4.7

HTTP常用請求方式:MethodGET、POST、HEAD、PUT、DELETE、TRACE、OPTIONS

6.訪問資源：

伺服器獲取請求報文中請求的資源web伺服器，即存放了web資源的伺服器，負責向請求者提供對方請求的靜態資源，或動態執行後生成的資源

資源放置於本地檔案系統特定的路徑：DocRoot DocRoot → /var/www/html /var/www/html/images/logo.jpg http://www.magedu.com/images/logo.jpg web伺服器資源路徑對映方式： (a) docroot (b) alias (c) 虛擬主機docroot(d) 使用者家目錄docroot

7. 返回處理結果，準備http響應:

響應報文包含:a) 狀態行:http版本(1.1或者1.0),狀態碼200:請求正常處理304:返回上次請求資源未作改動,驗證瀏覽器的快取機制400:請求引數錯誤401:客戶端無權訪問,要去輸入使用者名稱\密碼之類的授權資訊403:禁止訪問(讀寫許可權等影響)404:請求的資源不存在500:服務內部錯誤502:閘道器錯誤503:臨時過載或者維護,導致服務端無法正常處理請求b) 首部報文支援的語言\編碼格式\等,注意If-Modified-Since:只有當所請求的內容在指定的日期之後又經過修改才返回它，否則返回304“Not Modified”應答,用於服務端快取校驗c) 空行d) 響應報文實體

8. 透過建立的tcp連線來返回相關的http響應報文及http狀態資訊，然後根據實際情況看是否關閉連線(Connection的keep-alive)

9. TCP連線關閉經歷4次握手

客戶端主動關閉連線放傳送FIN進入FIN_WAIT1狀態

服務端發最後的data和ack客戶端接收進入CLOSEWAIT狀態,客戶端進入接受ACK進入FINWAIT2狀態

服務端主動發FIN,客戶端接受FIN併發送ack進入TIMEWAIT狀態

伺服器端正式關閉連線進入close狀態

10. 客戶端拿到http響應的報文資訊，經過一系列前端處理過程最終將請求的資源進行展示。

一，在瀏覽器位址列輸入網址

二，解析域名，找到主機的ip地址

三，瀏覽器與主機建立TCP連線

四，瀏覽器向主機發起GET請求

五，伺服器響應請求，返回html頁面

六，瀏覽器開始顯示伺服器返回的頁面，並且在顯示html頁面的時候，如果遇見css檔案，js檔案，圖片，就又會再次給相應地址伺服器發起請求。

專業問題我來回答，

背景HTTP（HyperText Transfer Protocol超文字傳輸協議），該協議位於OSI模型的應用層，應用層是開放系統的最高層，是程式設計師能直接操縱的通訊層。一次HTTP的請求主要建立在傳輸層TCP三次握手建立通訊和四次分手斷開通訊的基礎上，應用層在TCP建立好通訊線路後直接傳送資料到對端伺服器上。TCP：TCP是一種面向連線的可靠傳輸協議，為什麼說它是一種可靠的傳輸協議，就在於他這種三次握手和四次分手的機制，透過握手能定時重傳，序號確認，資料包校驗，擁塞控制來達到可靠傳輸。當然UDP是不建立這種可靠傳輸的因而沒有握手機制。TCP三次握手和四次分手

所謂三次握手(Three-way Handshake)，是在建立通訊過程中，服務端和客戶端總共傳送三次資料包。三次握手的目的是：建立TCP通訊，和對方同步序列號和確認號，交換通訊視窗的大小等。

第一次握手（SYN=1,seq=x）：客戶端向服務端傳送一個TCP標誌位SYN為1的資料包，表明要與服務端指定的埠建立連線，同時知名該資料包的第一個位元組的序號為seq=X,傳送完畢後，客戶端進入SYN-END狀態。第二次握手(SYN=1,ACK=1，ack=x+1,seq=y)：服務端向客戶端傳送一個同步確認包（SYN=1,ACK=1），確認號為x+1，表明自己已經收到序號為x開始的資料包，並向客戶端傳送一個序號為seq=y的包，傳送完畢後，伺服器端進入 SYN_RCVD 狀態。第三次握手（ACK=1,seq=x+1,ack=y+1）:此時客戶端向服務端傳送一個確認包（ACK=1），同時確認號為y+1，表明客戶端已經接受到伺服器以y序號開始的資料包，傳送完畢後，客戶端進入 ESTABLISHED 狀態，當伺服器端接收到這個包時，也進入 ESTABLISHED 狀態，TCP握手結束。第一次揮手（FIN=1,seq=u）:客戶端向服務端傳送FIN=1的包，表明要斷開通訊，同時傳送一個序號seq=u的資料包；第二次揮手（ACK=1,seq=v,ack=u+1）:服務端向客戶端傳送一個確認資料包（ACK=1）,同時傳送一個序列號為seq=v的資料包。第三次揮手（FIN=1，ACK=1,seq=w,ack=u+1）：FIN=1，表明服務端同意斷開通訊鏈路，這個包同樣是確認包（ACK=1）,因為服務端傳送的兩次確認包之間客戶端並沒有傳送資料包給服務端，所以確認號都是ack=u+1;第四次揮揮手（ACK=1,seq=u+1,ack=w+1）:服務端向客戶端傳送確（ACK=1），同時傳送一個序列號為u+1的包。至此，通訊鏈路斷開。完整的HTTP請求過程

1.建立TCP連線：只有當TCP建立完成後才能進行通訊。

2.客戶端向服務端發起請求：該階段應用層透過HTTP協議組裝請求包透過傳輸層網路層和資料鏈路層到達伺服器。

3.客戶端向服務端傳送請求頭資訊：在這一步客戶端將請求頭資訊組裝在各類頭部欄位中，進行傳送。

4.服務端向客戶端傳送響應：服務端接收到客戶端的請求資訊後，做出響應來客戶端。

5.服務端向客戶端傳送響應報文的頭部欄位：將響應資料包的頭部欄位傳送給客戶端。

6.服務端向客戶端傳送響應資料：透過Body將響應資料給客戶單，而這些資料才是客戶端要獲取的。

7.關閉通訊線路：資料傳送完畢後，如果是短連線將馬上關閉通訊線路，如果是長連線，服務端會透過同步資訊Connection:keep-alive來告訴客戶端。

以上，就是一個完整HTTP請求的流程，其主要在於TCP建聯，後續都是應用層之間的互動來通訊。

我大致把這個問題查了個遍，寫個最通俗的版本給大家看看吧。

其實HTTP請求過程，就是傳送請求—響應的過程。

第一步

今天你想起來，有事，需要找隔壁老王要個小影片。於是，你打開了“TCP協議牌”機器，這是一臺高畫質組裝的行動電話機。

①TCP告訴你，電話線路連線通道正在接通……第二步

電話接通了，在影片上出現了隔壁老王那張猥瑣的笑臉。

你開始說話。

接下來，就要開始做正事了。

第三步1.你說：

哎呀老王呀，我這邊需要一個小電影，你能給我發過來嗎？(客戶端傳送請求資訊)

2.接著，沒等老王說話，你就把需要的小電影名字、大小、我這網速等等資訊給他發了過去(客戶端傳送頭部資訊)，末尾還加上了一長串省略空格(以空格做結尾)。

第四步

老王皺皺眉頭。

“行吧！”(伺服器端迴應請求資訊)

“你是要這個小電影《XXX》，番號XXX，1GB大小，某度網盤是吧？行！”(伺服器端迴應頭部資訊)

老王動了動手指，查找了一下儲存卡目錄，翻出小電影。

“我給你發過去了！”(伺服器端傳送請求資料)

第五步你：哎呀哎呀，收到了！謝謝老王哈！下次請你吃飯！那我就先關閉了！(第一次揮手)老王：最後跟你說一句，少看小電影！(第二次揮手)老王：那我就先關閉了？(第三次揮手)你：行，那你關閉吧！(第四次揮手)

影片聊天結束。你隨即開啟收到的抖音小影片，美滋滋的看起成都小甜甜姐姐起來。

這件事告訴我們：

我還沒有女朋友。

如果URL透過驗證，那麼可以解析得到協議（http或者https）、域名（wukong）、資源（首頁）等資訊。

DNS查詢

瀏覽器會先檢查域名資訊是否在快取中。

再檢查域名是否在本地的Hosts檔案中。

如果還不在，那麼瀏覽器會向DNS伺服器傳送一個查詢請求，獲得目標伺服器的IP地址。

TCP封包及傳輸

這時候瀏覽器獲得了目標伺服器的IP（DNS返回）、埠（URL中包含，沒有就使用預設），瀏覽器會呼叫庫函式socket，生成一個TCP流套接字，也就是完成了TCP的封包。

TCP封包完成之後，就可以傳輸了，在完成“你瞅啥”，“瞅你咋地”，“來，過來嘮嘮”一系列操作之後，瀏覽器和伺服器就完成了TCP的三次握手，建立了連線，後面就可以請求伺服器資源了。

伺服器接收請求並相應

HTTP有很多請求方法，比如：GET/POST/PUT/DELETE等等，我們瀏覽器輸入URL這種，是GET方法。

伺服器接收到GET請求，伺服器根據請求資訊，獲得相應的相應內容。例如我們輸入的是：\www.wukong.com\，那麼意味著訪問首頁檔案。

瀏覽器解析並渲染

瀏覽器從伺服器拿到了想要訪問的資源，大多數時候，這個資源就是HTML頁面，當然也可能是一個其他型別的檔案。

瀏覽器先對HTML文件進行解析，生成解析樹（以DOM元素為節點的樹）。

載入頁面的外部資源，比如JS、CSS、圖片。

遍歷DOM樹，並計算每個節點的樣式，最終完成渲染，變成我們看到的頁面。

這次請求響應之後，會斷開連線，就這樣，完成了一次HTTP的請求。

一次完整的http請求過程是怎樣的？

一次完整的http請求可以說相當迷人：

1、首先瀏覽器會解析你輸入的這一串字元；主要是解析協議（HTTP（s）、ftp：）、域名（www.qq.com)等；如果是合法的網址就繼續進行；

2、接下啦就是要根據第一步解析到的域名找到域名指向的IP我們稱之為DNS查詢。當然這也是一個相對有趣的過程，但不是問題重點，此處簡略；

3、找到伺服器的IP地址後寫下來就是http請求的開始：

三次握手建立連線：

客戶端：“在嗎？”；

服務端：“在啊”；

客服端 ：“那我開始連你啦”；開始發起http請求

建立連線後發生Http請求，請求內容有：

請求行：uri和協議的版本 (如：GET /index.php HTTP/1.1 )

請求頭部：關客戶端資訊及請求正文資訊（長度、編碼格式等）

請求資料：如：u=admin&pwd=123456 （可為空）

服務端在收到這些資訊後作出相應的回答：

狀態：協議版本+狀態碼+簡要描述（如：HTTP/1.1 200 OK）

響應頭部：Content-Type（必須有：比如Content-Type: text/html）， 其他可選：Date 、server 等

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

開啟瀏覽器=》F12 訪問一下百度看一下這個完美的過程吧！

當然其中涉及的到東西遠不止這些，比如瀏覽器靜態檔案的快取；各個狀態碼含義；單次請求最大返回資源數；請求位元組長度限制等等。

此處班門弄斧，如有錯誤請批評指正。

前言

今天我們來徹底聊聊，什麼是TCP/IP、http、socket、長連線、短連線

TCP/IP

TCP/IP是協議組，分為三個層次：

網路層傳輸層應用層。

在網路層有：

IP協議ICMP協議ARP協議RARP協議BOOTP協議

在傳輸層中有：

TCP協議UDP協議

在應用層有：

TCP包括:

FTP協議HTTP協議TELNET協議SMTP協議

UDP包括：

DNS協議TFTP協議短連線

流程：連線->傳輸資料->關閉連線

HTTP是無狀態的，瀏覽器和伺服器每進行一次HTTP操作，就建立一次連線，但任務結束就中斷連線。

也可以這樣說：短連線是指SOCKET連線後傳送後接收完資料後馬上斷開連線。

長連線

流程：連線 -> 傳輸資料 -> 保持連線 -> 傳輸資料 -> 。。。-> 關閉連線。

長連線指建立SOCKET連線後不管是否使用都保持連線，但安全性較差。

http的長連線

HTTP也可以建立長連線的，使用Connection:keep-alive，HTTP 1.1預設進行長連線。

HTTP1.1 和 HTTP1.0 相比較而言，最大的區別就是增加了長連線支援(貌似最新的 http1.0 可以顯示的指定 keep-alive)，但還是無狀態的，或者說是不可以信任的。

什麼時候用長連線，短連線？

長連線多用於操作頻繁，點對點的通訊，而且連線數不能太多情況。

每個TCP連線都需要三步握手，這需要時間，如果每個操作都是先連線，再操作的話那麼處理速度會降低很多。

所以每個操作完後都不斷開，次處理時直接傳送資料包就OK了，不用建立TCP連線。

例如：資料庫的連線用長連線， 如果用短連線頻繁的通訊會造成socket錯誤，而且頻繁的socket 建立也是對資源的浪費。

而像WEB網站的http服務一般都用短連結，因為長連線對於服務端來說會耗費一定的資源。

而像WEB網站成千上萬甚至上億客戶端的頻繁連線，用短連線會更省一些資源，如果用長連線，而且同時有成千上萬的使用者，如果每個使用者都佔用一個連線的話，那可想而知吧。

所以併發量大，但每個使用者無需頻繁操作情況下需用短連好。

總之，長連線和短連線的選擇要視情況而定。

資料傳送接收方式

非同步

報文傳送和接收是分開的，相互獨立的，互不影響。這種方式又分兩種情況：

非同步雙工：接收和傳送在同一個程式中，由兩個不同的子程序分別負責傳送和接收非同步單工：接收和傳送是用兩個不同的程式來完成。

同步

報文傳送和接收是同步進行，既報文傳送後等待接收返回報文。

同步方式一般需要考慮超時問題，即報文發出去後不能無限等待，需要設定超時時間，超過該時間傳送方不再等待讀返回報文，直接通知超時返回。

在長連線中一般是沒有條件能夠判斷讀寫什麼時候結束，所以必須要加長度報文頭。讀函式先是讀取報文頭的長度，再根據這個長度去讀相應長度的報文。

Socket是什麼

Socket是應用層與TCP/IP協議族通訊的中間軟體抽象層，它是一組介面（TCP/IP是協議，Socket是他們的具體實現和對外api）。

在設計模式中，Socket其實就是一個門面模式，它把複雜的TCP/IP協議族隱藏在Socket介面後面。

對使用者來說，一組簡單的介面就是全部，讓Socket去組織資料，以符合指定的協議。

Socket 通訊示例

主機 A 的應用程式要能和主機 B 的應用程式通訊，必須透過 Socket 建立連線，而建立 Socket 連線必須需要底層 TCP/IP 協議來建立 TCP 連線。

建立 TCP 連線需要底層 IP 協議來定址網路中的主機。

我們知道網路層使用的 IP 協議可以幫助我們根據 IP 地址來找到目標主機，但是一臺主機上可能執行著多個應用程式，如何才能與指定的應用程式通訊就要透過 TCP 或 UPD 的地址也就是埠號來指定。

這樣就可以透過一個 Socket 例項唯一代表一個主機上的一個應用程式的通訊鏈路了。

建立通訊鏈路(有點燒腦，可繞過)

當客戶端要與服務端通訊，客戶端首先要建立一個 Socket 例項，作業系統將為這個 Socket 例項分配一個沒有被使用的本地埠號，並建立一個包含本地和遠端地址和埠號的套接字資料結構。

這個資料結構將一直儲存在系統中直到這個連線關閉。在建立 Socket 例項的建構函式正確返回之前，將要進行 TCP 的三次握手協議，TCP 握手協議完成後，Socket 例項物件將建立完成，否則將丟擲 IOException 錯誤。

與之對應的服務端將建立一個 ServerSocket 例項，ServerSocket 建立比較簡單隻要指定的埠號沒有被佔用，一般例項建立都會成功，同時作業系統也會為 ServerSocket 例項建立一個底層資料結構，這個資料結構中包含指定監聽的埠號和包含監聽地址的萬用字元，通常情況下都是“*”即監聽所有地址。

之後當呼叫 accept() 方法時，將進入阻塞狀態，等待客戶端的請求。當一個新的請求到來時，將為這個連線建立一個新的套接字資料結構，該套接字資料的資訊包含的地址和埠資訊正是請求源地址和埠。

這個新建立的資料結構將會關聯到 ServerSocket 例項的一個未完成的連線資料結構列表中，注意這時服務端與之對應的 Socket 例項並沒有完成建立，而要等到與客戶端的三次握手完成後，這個服務端的 Socket 例項才會返回，並將這個 Socket 例項對應的資料結構從未完成列表中移到已完成列表中。所以 ServerSocket 所關聯的列表中每個資料結構，都代表與一個客戶端的建立的 TCP 連線。