域名解析
- 瀏覽器會先從本地緩存中查找域名的IP，如果查找到並且沒有過期，則解析成功；如果未找到或過期則進入步驟2
- 瀏覽器搜索操作系統自身的DNS緩存，如果找到且沒有過期，則解析成功；如果未找到或過期則進入步驟3
- 嘗試讀取hosts文件，找到對應的IP則解析成功；如果未找到則進入步驟4
- 瀏覽器趙Tcp/Ip中設置的本地DNS服務器，如果要查詢的域名包含在本地配置的區域資源中，則返回；否則本地DNS服務器會請求根DNS服務器
- 本地DNS把請求發送到根服務器，根服務器根據後綴(.com等)，返回IP，本地再用該IP聯繫（.com等）服務器，（.com等）服務器如果無法解析，則返回(baidu)服務其的IP，本地再去聯繫(baidu)服務器，(baidu)服務器返回(www.baidu.com)的ip
TCP三次握手
準備知識：
- ACK，TCP協議規定只有ACK=1時有效，也規定連接建立後所有發送的報文的ACK必須爲1
- SYN，在連接建立時用來同步序號。當SYN=1而ACK=0時，表明這是一個連接請求報文。對方若同意建立連接，則應在響應報文中使SYN=1和ACK=1，因此SYN置1就表示這是一個連接請求或連接接受報文
- FIN，用來釋放一個連接。當 FIN = 1 時，表明此報文段的發送方的數據已經發送完畢，並要求釋放連接。
三次握手
- 首先由Client發出請求連接即 SYN=1 ACK=0，TCP規定SYN=1時不能攜帶數據，但要消耗一個序號，因此聲明自己的序號是 seq=x
- 然後 Server 進行回覆確認，即 SYN=1 ACK=1 seq=y，ack=x+1
- 再然後 Client 再進行一次確認，但不用SYN 了，這時即爲 ACK=1，seq=x+1， ack=y+1
爲什麼要三次握手？
防止已失效的連接請求保溫突然又傳到B，因而產生錯誤。
假設A->B發了一個連接請求c，但是c由於某些原因滯留了，這時A->B又發了一個連接請求d；這種情況如果兩次就建立連接，則d請求建立好連接後，傳輸數據；這時c請求也過來了，B也建立了連接，並等待A數據的到來，這樣B的許多資源就浪費了
而三次握手，c請求給B後，B給A再發送時，A會校驗，發現c是過期的，則不會發確認，連接也就建立不成功
四次揮手
- 當客戶端沒有東西要發送時就要釋放連接的時候（注意這裏首先提出中斷連接端可以是Client端，也可以是Server端），客戶端會發送一個FIN爲1的沒有數據的報文，進入FIN_WAIT狀態，服務器收到後會給客戶端一個確認，這時客戶端那邊不再發送數據信息（但仍可接收信息）
- 客戶端收到服務器的確認後進入等待狀態，等待服務器請求釋放連接。 服務器數據發送完成後就向客戶端請求連接釋放（也是用FIN=1 表示，並且用ack = u+1(如圖））， 客戶端收到後回覆一個確認信息，又要進入 TIME_WAIT 狀態（等待2MSL 時間，最大報文生存時間）。服務器收到後關閉連接。
最後這裏爲什麼還要等待呢？是防止最後一個ACK的丟失，服務器在超時後會重新發送FIN。如果客戶端這時收到FIN就知道最後一個ACK丟失了，會重發。否則客戶端等待一段時間後依然沒有收到回覆，則證明Server端已正常關閉，那好，我客戶端也可以關閉連接了
注意：
- TIME_WAIT狀態中所需要的時間是依賴於實現方法的。典型的值爲30秒、1分鐘和2分鐘。
- 服務器存在一個保活狀態，即如果客戶端突然故障死機了，那B那邊的連接資源什麼時候能釋放呢？
就是保活時間到了後，B會發送探測信息，以決定是否釋放連接。 - 爲什麼連接的時候是三次握手，關閉的時候卻是四次揮手？
關閉連接時，當Server端收到FIN報文時，很可能數據信息沒有傳完並不會立即關閉連接，所以只能先回復一個ACK報文（告訴Client端，“你發的FIN報文我收到了”）。只有等到Server端所有的報文都發送完了，我才能發送FIN報文，因此不能一起發送。故需要四步揮手。
建立TCP連接後發起HTTP請求
TCP三次握手建立連接成功後，客戶端按照指定的格式開始向服務端發送HTTP請求，服務端接收請求後，解析HTTP請求，處理完業務邏輯，最後返回一個具有標準格式的HTTP響應給客戶端