當你在瀏覽器輸入一個URL 發生了什麼？
詳細過程：
- 瀏覽器通過DNS域名解析到服務IP
- 客戶端（瀏覽器）通過TCP協議建立到服務器的TCP連接；(三次握手)
- 客戶端（瀏覽器）向web服務器端（HTTP服務器）發送HTTP 協議包，請求服務器裏的資源文檔(telnet模擬)
- 服務器向客戶端發送HTTP協議應答包
- 客戶端和服務器斷開（四次揮手），客戶端開始解析HTML文檔
http要請求成功，必須通過TCP的三次握手才能與服務器連接。
http連接成功要基於TCP，
三次握手：首先客戶端發送一個SYM的數據包， (seq = client-isn)然後客戶端就處於一個send的狀態，然後客戶端就等服務器給它一個確認 ，這是第一次握手；二次握手，服務器收到包之後，必須確認客戶端SYM包，怎樣確認的呢？先把SYM包轉換成ACK包，ACK包會把剛纔seq包+1，同時自己會發送sym包，然後客戶端會收到，確實是之前自己發送的包，並且加了1返回。拿到SYM包之後它也把SYM包加1給返回出去了。這個時候三次握手建立完成。
1、先Client 發送連接、請求報文。
2、Server端接受連接後回覆ACK報文，併爲此次連接分配資源
3、Client端接受ACK報文之後也向服務器端發送ACK報文，並分配資源，這樣TCP就建立了。
四次揮手：
1、Client 端發起中斷連接請求，也就是發送FIn報文。Server端接到FIN報文之後，意思是說：“我Client端沒有數據要發給你了”，但是如果你還有數據沒發送完成，則不必急着關閉（Socket）,可以繼續發送數據。
2、Server發送ACK，告訴Clien端，“你的請求我收到了，但是我還沒準備號，請繼續等我的消息”。
wait：這個時候Client端就進入FIN_WAIT撞他，繼續等待Server站的FIN報文。
3、當Server端確定數據已發送完成，則向Client端發送FIN報文，告訴Client端，”好了，我這邊數據發送完了，準備好關閉連接了“。
4、客戶端收到FIN報文後，就知道可以關閉連接了，但是它還是不相信網絡，怕Server端不知道要關閉，所以發送ACK後進入TIME_Wait狀態。如果Server端沒有收到ACk則可以重傳。Server端收到ACK後，就知道可以斷開連接了。客戶端等待2MSL後沒有收到回覆，則證明Server端已正常關閉。那麼我（客戶端）也可以關閉連接了。這樣TCP連接就這樣關閉。
fin 表示斷開連接 ACK表示響應
報文：發送報文，響應也用報文
爲什麼客戶端在TIME_WAIT狀態必須等待2MSL時間呢？
1、第一，爲了保證客戶端發送的最後一個ACK報文段能夠到達Server端。這個ACK報文段有可能丟失，因而使服務器端收不到已經發送的ACK報文段的確認。B超時重傳這個FIN ，客戶端就能在2MSL時間內收到這個重傳的FIN，接着客戶端還要重傳一次確認，重新啓動2MSL計時。如果客戶端不在TIME_WAIT等待一段時間，而是在發送完ACK報文段後立即釋放連接，就無法收到服務器端重傳的FIN，因而也不會再發送一次確認報文段。這樣B就不能正常關閉。
2、第二，防止“已失效的連接請求報文段”出現在本連接中。客戶端發送完最後一個ACK報文段後，再經過時間2MSL，就可以使本連接持續的時間內所產生的所有報文段都從網路消失。這樣就可以使下一個新的連接中不會出現這種的連接請求報文段。
已經失效的連接請求報文段是這樣產生的
考慮到一種正常情況：
客戶端發出連接請求，但因連接請求報文丟失而未收到確認。於是客戶端再重傳一次連接請求。後來收到確認，重新連接連接。數據傳輸完畢後，就釋放了連接。客戶端共發送了兩個連接請求報文段，但是第一個丟失，第二個到達了B。
異常情況的考慮：
即客戶端發出的第一個連接請求報文段沒有丟失，而是在某些網絡結點長時間滯留了，以致延誤到連接釋放以後的某個時間纔到達服務器。本來這是一個早已失效的報文段，但是服務器收到此失效的連接請求報文段之後，誤認是客戶端重新發送的新的請求。於是就向Client發出確認報文段，同意建立連接。因爲客戶端沒有發出建立連接請求，只是服務端收到報廢的報文段，所以客戶端不會理服務端的確認，這樣服務端就一直在等待之中，許多資源就這樣白白浪費。
注意：採用三次握手就可以防止“已失效的連接請求報文段”現象的發生。