簡介 TCP 和 UDP 區(qū)別，他們位于哪一層？

TCP --- 傳輸控制協(xié)議,提供的是面向連接勒叠、可靠的字節(jié)流服務(wù)。當(dāng)客戶和服務(wù)器彼此交換數(shù)據(jù)前膏孟，必須先在雙方之間建立一個TCP連接眯分，之后才能傳輸數(shù)據(jù)。TCP提供超時重發(fā)柒桑，丟棄重復(fù)數(shù)據(jù)弊决，檢驗(yàn)數(shù)據(jù)，流量控制等功能魁淳，保證數(shù)據(jù)能從一端傳到另一端丢氢。 理想狀態(tài)下，TCP連接一旦建立先改，在通信雙方中的任何一方主動關(guān)閉連接前疚察，TCP 連接都將被一直保持下去。斷開連接時服務(wù)器和客戶端均可以主動發(fā)起斷開TCP連接的請求

UDP --- 用戶數(shù)據(jù)報協(xié)議仇奶，是一個無連接的簡單的面向數(shù)據(jù)報的運(yùn)輸層協(xié)議貌嫡。UDP不提供可靠性比驻，它只是把應(yīng)用程序傳給IP層的數(shù)據(jù)報發(fā)送出去，但是并不能保證它們能到達(dá)目的地岛抄。由于UDP在傳輸數(shù)據(jù)報前不用在客戶和服務(wù)器之間建立一個連接别惦，且沒有超時重發(fā)等機(jī)制，故而傳輸速度很快

位于 OSI 七層模型的第四層（由下往上）傳輸層

路由器和交換機(jī)的工作原理大概是什么夫椭，他們分別用到什么協(xié)議掸掸，位于哪一層？

交換機(jī)主要基于網(wǎng)橋技術(shù)蹭秋，用于組建局域網(wǎng)扰付，局域網(wǎng)中的終端與終端可以進(jìn)行數(shù)據(jù)交換；路由器主要基于路由選擇技術(shù)仁讨，用于將數(shù)據(jù)路由到上層網(wǎng)路的正確路徑中羽莺。

交換機(jī)工作在數(shù)據(jù)鏈路層（7層網(wǎng)絡(luò)協(xié)議的第二層）；路由器工作在網(wǎng)絡(luò)層（7層網(wǎng)絡(luò)協(xié)議的第三層）洞豁。

交換機(jī)識別的是MAC地址盐固；路由器識別的是IP地址。

描述TCP 協(xié)議三次握手丈挟，四次釋放的過程刁卜。

第一次握手：客戶端發(fā)送syn包(syn=j)到服務(wù)器，并進(jìn)入SYN_SEND狀態(tài)曙咽，等待服務(wù)器確認(rèn)长酗；

第二次握手：服務(wù)器收到syn包，必須確認(rèn)客戶的SYN（ack=j+1）桐绒，同時自己也發(fā)送一個SYN包（syn=k）夺脾，即SYN+ACK包，此時服務(wù)器進(jìn)入SYN_RECV狀態(tài)茉继；

第三次握手：客戶端收到服務(wù)器的SYN＋ACK包咧叭，向服務(wù)器發(fā)送確認(rèn)包ACK(ack=k+1)，此包發(fā)送完畢烁竭，客戶端和服務(wù)器進(jìn)入ESTABLISHED狀態(tài)菲茬，完成三次握手。

四次握手關(guān)閉連接：
（客戶端）：我要關(guān)閉連接了派撕。
（服務(wù)端）：你那邊的連接可以關(guān)閉了婉弹。
（服務(wù)端）：我這邊也要關(guān)閉連接了。
（客戶端）：你那邊的連接可以關(guān)閉了终吼。
由于連接是雙向的镀赌，所以雙方都要主動關(guān)閉自己這一側(cè)的連接。

TCP 協(xié)議是如何進(jìn)行流量控制际跪，擁塞控制的商佛？

1喉钢、通信開始時，發(fā)送方的擁塞窗口大小為 1良姆。每收到一個 ACK 確認(rèn)后肠虽，擁塞窗口翻倍。
2玛追、由于指數(shù)級增長非乘翱危快，很快地痊剖，就會出現(xiàn)確認(rèn)包超時韩玩。
3、此時設(shè)置一個“慢啟動閾值”邢笙，它的值是當(dāng)前擁塞窗口大小的一半啸如。
4侍匙、同時將擁塞窗口大小設(shè)置為 1氮惯，重新進(jìn)入慢啟動過程。
5想暗、由于現(xiàn)在“慢啟動閾值”已經(jīng)存在妇汗，當(dāng)擁塞窗口大小達(dá)到閾值時，不再翻倍说莫，而是線性增加杨箭。
6、隨著窗口大小不斷增加储狭，可能收到三次重復(fù)確認(rèn)應(yīng)答(發(fā)送方意識到接收方?jīng)]收到數(shù)據(jù)互婿，所以重發(fā))，進(jìn)入“快速重發(fā)”階段辽狈。
7慈参、這時候，TCP 將“慢啟動閾值”設(shè)置為當(dāng)前擁塞窗口大小的一半刮萌，再將擁塞窗口大小設(shè)置成閾值大型耘洹（也有說加 3）。
8着茸、擁塞窗口又會線性增加壮锻，直至下一次出現(xiàn)三次重復(fù)確認(rèn)應(yīng)答或超時。

為什么建立連接時是三次握手涮阔，兩次行不行猜绣？如果第三次握手失敗了怎么處理

根據(jù)一般的思路，我們可能會覺得只要兩次握手就可以了敬特，第三步確認(rèn)看似是多余的途事。那么 TCP 協(xié)議為什么還要費(fèi)力不討好的加上這一次握手呢验懊？

這是因?yàn)樵诰W(wǎng)絡(luò)請求中，我們應(yīng)該時刻記资洹：“網(wǎng)絡(luò)是不可靠的义图，數(shù)據(jù)包是可能丟失的”。假設(shè)沒有第三次確認(rèn)召烂，客戶端向服務(wù)端發(fā)送了 SYN碱工，請求建立連接。由于延遲奏夫，服務(wù)端沒有及時收到這個包怕篷。于是客戶端重新發(fā)送一個 SYN 包⌒镏纾回憶一下介紹 TCP 首部時提到的序列號廊谓，這兩個包的序列號顯然是相同的。

假設(shè)服務(wù)端接收到了第二個 SYN 包麻削，建立了通信蒸痹，一段時間后通信結(jié)束，連接被關(guān)閉呛哟。這時候最初被發(fā)送的 SYN 包剛剛抵達(dá)服務(wù)端叠荠，服務(wù)端又會發(fā)送一次 ACK 確認(rèn)。由于兩次握手就建立了連接扫责，此時的服務(wù)端就會建立一個新的連接榛鼎，然而客戶端覺得自己并沒有請求建立連接，所以就不會向服務(wù)端發(fā)送數(shù)據(jù)鳖孤。從而導(dǎo)致服務(wù)端建立了一個空的連接者娱，白白浪費(fèi)資源。

在三次握手的情況下苏揣，服務(wù)端直到收到客戶端的應(yīng)答后才會建立連接黄鳍。因此在上述情況下，客戶端會接受到一個相同的 ACK 包腿准，這時候它會拋棄這個數(shù)據(jù)包际起，不會和服務(wù)端進(jìn)行第三次握手，因此避免了服務(wù)端建立空的連接吐葱。

關(guān)閉連接時街望，第四次握手失敗怎么處理？

實(shí)際上弟跑，在第三步中灾前，客戶端收到 FIN 包時，它會設(shè)置一個計(jì)時器孟辑，等待相當(dāng)長的一段時間哎甲。如果客戶端返回的 ACK 丟失蔫敲，那么服務(wù)端還會重發(fā) FIN 并重置計(jì)時器。假設(shè)在計(jì)時器失效前服務(wù)器重發(fā)的 FIN 包沒有到達(dá)客戶端炭玫，客戶端就會進(jìn)入 CLOSE 狀態(tài)奈嘿，從而導(dǎo)致服務(wù)端永遠(yuǎn)無法收到 ACK 確認(rèn)，也就無法關(guān)閉連接吞加。

你怎么理解分層和協(xié)議裙犹？

HTTP 請求中的GET 和 POST 的區(qū)別，Session 和 Cookie 的區(qū)別衔憨。

GET 請求通常用于查詢叶圃、獲取數(shù)據(jù)，而 POST 請求則用于發(fā)送數(shù)據(jù)践图，除了用途上的區(qū)別霞揉，它們還有以下這些不同：

GET 請求可以被緩存拨拓，可以被收藏為書簽扫沼，但 POST 不行瓦胎。
GET 請求會保留在瀏覽器的歷史記錄中阶捆，POST 不會酗失。
GET 請求的長度有限制（不同的瀏覽器不一樣启具，大約在幾 Kb 左右）蕊玷，URL 的數(shù)據(jù)類型只能是 ASCII 字符心赶，POST 請求沒有限制扣讼。
GET 請求的參數(shù)在 URL 中，因此絕不能用 GET 請求傳輸敏感數(shù)據(jù)缨叫。POST 請求數(shù)據(jù)則寫在 HTTP 的請求頭中椭符，安全性略高于 GET 請求。
注意：

POST 請求僅比 GET 請求略安全一點(diǎn)耻姥，它的數(shù)據(jù)不在 URL 中销钝，但依然以明文的形式存放于 HTTP 的請求頭中。

cookie 琐簇、session 這兩者的根本性區(qū)別在于蒸健，cookie 保存在客戶端上，而 session 則保存在服務(wù)器中婉商。由此我們還可以拓展出以下結(jié)論：
1似忧、cookie 相對來說不安全，瀏覽器可以分析本地的 cookie 進(jìn)行 cookie 欺騙丈秩。
2盯捌、session 可以設(shè)置超時時間，超過這個時間后就失效蘑秽，以免長期占用服務(wù)端內(nèi)存饺著。
3箫攀、單個 cookie 的大小有限制（4 Kb），每個站點(diǎn)的 cookie 數(shù)量一般也有限制（20個）幼衰。
4靴跛、客戶端每次都會把 cookie 發(fā)送到服務(wù)端，因此服務(wù)端可以知道 cookie渡嚣，但是客戶端不知道 session汤求。
5、當(dāng)服務(wù)器接收到 cookie 后严拒，會根據(jù) cookie 中的 SessionID 來找到這個客戶的 session扬绪。如果沒有，則會生成一個新的 SessionID 發(fā)送給客戶端裤唠。

談?wù)勀銓?HTTP 1.1挤牛，2.0 和 HTTPS 的理解。

HTTPS是安全的HTTP