概述：我們在網(wǎng)址中輸入域名求类，首先會經(jīng)過DNS的域名解析拿到具體的ip地址居触。隨后客戶端和服務(wù)端開始通過三次握手來開始建立連接搬味，連接建立成功之后，客戶端將包裝好的http請求傳輸?shù)椒?wù)端逸嘀，服務(wù)端處理后再將數(shù)據(jù)返回給客戶端车要。當(dāng)客戶端或者服務(wù)端不再有數(shù)據(jù)需要發(fā)送給對方的時候，就會開始發(fā)起四次回收以斷開連接崭倘。
三次握手
解釋一下幾個表示位：
SYN(synchronous建立聯(lián)機)?
ACK(acknowledgement 確認)?
PSH(push傳送)
?FIN(finish結(jié)束)?
RST(reset重置)
?URG(urgent緊急)
Sequence number(順序號碼)?
Acknowledge number(確認號碼)
第一次握手客戶端需要發(fā)送一個syn=1告訴服務(wù)端需要聯(lián)機翼岁，并且會同時發(fā)送一個隨機生成的順序號碼（seq）。
第二次握手由服務(wù)端發(fā)起司光，服務(wù)端需要回復(fù)客戶端一個確認ACK琅坡，這個值為第一次客戶端生成的順序號碼加1，另外也生成一個隨機順序號碼給到客戶端残家。
第三次握手由客戶端收到第二次握手的消息后榆俺，回復(fù)服務(wù)端一個確認消息ACK，這個值為服務(wù)端的順序號碼加1坞淮，也會發(fā)送一個seq茴晋。
很容易理解三次握手，第一次握手回窘，是客戶端需要確認自己發(fā)消息沒問題诺擅，服務(wù)端收到消息以后證明自己收消息沒問題，這時他還需要證明自己發(fā)消息沒問題所以他發(fā)起第二次握手啡直，客戶端收到第二次握手的消息后確認了自己的發(fā)消息和收消息都沒問題烁涌，但這時候服務(wù)端只知道自己收消息沒有問題，他第二次發(fā)出的消息他并不知道客戶端是否成功接收了酒觅，所以有了第三次握手撮执，告訴服務(wù)端我收到了，你發(fā)消息沒毛病舷丹。這時二打，就證明了客戶端和服務(wù)端雙方的收發(fā)都沒有問題。
*syn攻擊：偽造大量不存在的ip向服務(wù)端發(fā)送請求掂榔，第一次握手完成以后继效，使服務(wù)端進入半連接狀態(tài)，服務(wù)端回復(fù)的消息得不到客戶端的確認装获，服務(wù)端會反復(fù)確認瑞信，使得連接隊列一直被占用，正常的連接反而進不來穴豫。
HTTP請求報文
相信大多數(shù)開發(fā)有過f12凡简，然后network下面看請求和調(diào)用http接口時檢查請求報文的經(jīng)歷逼友。其實一個HTTP請求報文由請求行（request line）、請求頭部（header）秤涩、空行和請求數(shù)據(jù)4個部分組成帜乞。
1.請求行
請求行分為三個部分：請求方法、請求地址和協(xié)議版本
請求方法
最常的兩種get和post筐眷。
請求地址：就是URL
協(xié)議版本：如HTTP/1.0和HTTP/1.1
2.請求頭
常見的為：
3.請求參數(shù)
需要注意的是get的參數(shù)帶在url后面并不在這里黎烈。
數(shù)據(jù)送入?yún)f(xié)議棧
當(dāng)應(yīng)用程序用TCP傳送數(shù)據(jù)時，數(shù)據(jù)被送入?yún)f(xié)議棧中匀谣，然后逐個通過每一層直到被當(dāng)作一串比特流送入網(wǎng)絡(luò)照棋。其中每一層對收到的數(shù)據(jù)都要增加一些首部信息。
當(dāng)目的主機收到一個以太網(wǎng)數(shù)據(jù)幀時武翎，數(shù)據(jù)就開始從協(xié)議
棧中由底向上升烈炭，同時去掉各層協(xié)議加上的報文首部。每
層協(xié)議盒都要去檢查報文首部中的協(xié)議標識宝恶，以確定接收
數(shù)據(jù)的上層協(xié)議符隙。
HTTP響應(yīng)報文
HTTP響應(yīng)報文主要由狀態(tài)行、響應(yīng)頭部垫毙、空行以及響應(yīng)數(shù)據(jù)組成膏执。
狀態(tài)行
由3部分組成，分別為：協(xié)議版本露久，狀態(tài)碼，狀態(tài)碼描述欺栗。
其中協(xié)議版本與請求報文一致毫痕，狀態(tài)碼描述是對狀態(tài)碼的簡單描述，所以這里就只介紹狀態(tài)碼迟几。
狀態(tài)代碼為3位數(shù)字消请。
1xx：指示信息--表示請求已接收，繼續(xù)處理类腮。
2xx：成功--表示請求已被成功接收臊泰、理解、接受蚜枢。
3xx：重定向--要完成請求必須進行更進一步的操作缸逃。
4xx：客戶端錯誤--請求有語法錯誤或請求無法實現(xiàn)。
5xx：服務(wù)器端錯誤--服務(wù)器未能實現(xiàn)合法的請求厂抽。
四次揮手
通過前面需频，我們已經(jīng)知道ACK是用來應(yīng)答的，SYN是用來代表連接的筷凤。而這里的FIN報文就是代表斷開連接的昭殉，當(dāng)主動方?jīng)]有數(shù)據(jù)再需要傳輸給對方時苞七，會向?qū)Ψ桨l(fā)起FIN報文，但這時候被動方不會立馬斷開連接挪丢，他只會回復(fù)一個ACK告訴主動方你發(fā)的FIN報文我收到了蹂风，很可能不會立馬關(guān)閉，因為他可能還沒處理完請求乾蓬，可能還有消息需要發(fā)送惠啄，這時主動方進入FIN_WAIT_2狀態(tài)。等被動發(fā)也沒有消息需要發(fā)送了巢块，這時候才會也發(fā)一個FIN給主動方礁阁，主動方回復(fù)以后，連接斷開族奢。
COOKIE
Http 協(xié)議中引入了 cookie 技術(shù)姥闭，用來解決 http 協(xié)議無狀態(tài)的問題。通過在請求和響應(yīng)報文中寫入 Cookie 信息來控制客戶端的狀態(tài)越走；Cookie會根據(jù)從服務(wù)器端發(fā)送的響應(yīng)報文內(nèi)的一個叫做 Set-Cookie 的首部字段信息棚品，通知客戶端保存 Cookie。當(dāng)下次客戶端再往該服務(wù)器發(fā)送請求時廊敌，客戶端會自動在請求報文中加入 Cookie 值后發(fā)送出去铜跑。在基于 tomcat 這類的 jsp/servlet 容器中，會提供 session 這樣的機制來保存服務(wù)端的對象狀態(tài)骡澈。
