問題總結(jié)
1、cookie和session的區(qū)別
2、TCP的三次握手過程？為什么要三次握手？
【三次握手的過程】【三次握手的原因】
3、TCP四次揮手
【TCP四次揮手的過程】
【為什么連接的時(shí)候是三次握手，關(guān)閉的時(shí)候卻是四次握手？】
【等待 2MSL 的原因】
4、TCP和UDP的區(qū)別
5、HTTP 和 HTTPS的區(qū)別
6、TCP的擁塞控制
7、滑動(dòng)窗口
8、HTTP請(qǐng)求中GET和POST的區(qū)別

計(jì)算機(jī)網(wǎng)絡(luò)詳解

??一、cookie和session的區(qū)別（農(nóng)+1，）

（1）cookie只能存儲(chǔ)ASCII碼，而session可以存儲(chǔ)任何類型的數(shù)據(jù)
（2）session存儲(chǔ)在服務(wù)器中，而cookie存儲(chǔ)在客戶端中，容易被惡意查看
（3）session運(yùn)行依賴于session ID，而session ID為存在cookie中的JSESSIONID。如果瀏覽器禁用了cookie，同時(shí)session也會(huì)失效（可以通過其他方法實(shí)現(xiàn)，比如在URL中傳遞session）

待增加：cookie和session的機(jī)制是什么？

??二、TCP的三次握手過程？為什么要三次握手？（農(nóng)+1）

1、三次握手的過程

（1）建立TCP連接時(shí)，客戶端發(fā)送syn包到服務(wù)器，此時(shí)客戶端進(jìn)入SYN_SENT狀態(tài)，等待服務(wù)器確認(rèn)。
（2）服務(wù)器收到syn包，必須確認(rèn)客戶的SYN，并向客戶端發(fā)送SYN/ACK包，此時(shí)服務(wù)器進(jìn)入SYN_RECV狀態(tài)。
（3）客戶端收到SYN/ACK包，向服務(wù)器發(fā)送確認(rèn)包ACK，此包發(fā)送完畢，客戶端和服務(wù)器進(jìn)入established狀態(tài)，TCP連接成功，完成三次握手

2、三次握手的原因（農(nóng)+1）

（1）從信息對(duì)等角度看，客戶端和服務(wù)器端分別要確認(rèn)自己的發(fā)送和接受能力均正常，第二次握手后，服務(wù)器還不能確認(rèn)自己 的發(fā)送能力和對(duì)方的接收能力。
（2）客戶端的超時(shí)連接請(qǐng)求可能會(huì)在雙方釋放連接后后到達(dá)服務(wù)器，服務(wù)器端會(huì)誤以為是客戶端發(fā)送了新的請(qǐng)求，然后創(chuàng)建連接，造成服務(wù)器資源的浪費(fèi)。

image.png

??三、TCP四次揮手（農(nóng)+1）

【問題1】TCP四次揮手的過程

（1）當(dāng)客戶端沒有要發(fā)送的數(shù)據(jù)時(shí)會(huì)向服務(wù)器端發(fā)送終止連接報(bào)文FIN，發(fā)送后客戶端進(jìn)入FIN-WAIT-1狀態(tài)。
（2）服務(wù)器端收到FIN后發(fā)給客戶端一個(gè)ACK確認(rèn)報(bào)文，客戶端進(jìn)入FIN-WAIT-2狀態(tài)，服務(wù)端進(jìn)入CLOSE-WAIT狀態(tài)，TCP進(jìn)入半關(guān)閉狀態(tài)。
（3）當(dāng)服務(wù)器端數(shù)據(jù)全部發(fā)送完畢就向客戶端發(fā)送終止連接報(bào)文FIN，之后服務(wù)器端進(jìn)入LAST-ACK狀態(tài)。
（4）客戶端收到FIN報(bào)文后，還需向服務(wù)器端發(fā)送ACK報(bào)文進(jìn)行再一次確認(rèn)，發(fā)送之后客戶端進(jìn)入TIME-WAIT狀態(tài)，等到2MSL后進(jìn)入CLOSED狀態(tài)，服務(wù)器收到確認(rèn)后進(jìn)入CLOSED狀態(tài)

【問題2】為什么連接的時(shí)候是三次握手，關(guān)閉的時(shí)候卻是四次握手？

因?yàn)楫?dāng)服務(wù)器端收到客戶端的SYN的連接請(qǐng)求報(bào)文之后，可以直接發(fā)送SYN+ACK報(bào)文，其中ACK報(bào)文是用來應(yīng)答的，SYN報(bào)文是用來同步的。但是關(guān)閉連接時(shí)，當(dāng)服務(wù)器端收到FIN報(bào)文時(shí)，很可能并不會(huì)直接關(guān)閉SOCKET，所以只能先回復(fù)一個(gè)ACK報(bào)文，告訴客戶端收到了FIN報(bào)文的消息，只有等到服務(wù)器端數(shù)據(jù)全部發(fā)送完畢，服務(wù)器端才向客戶端發(fā)送FIN報(bào)文，所以需要四次揮手。

【問題3】等待 2MSL 的原因

（1）MSL是最大報(bào)文壽命，等待2MSL可以保證客戶端發(fā)送的最后一個(gè)確認(rèn)報(bào)文ACK被服務(wù)器端接收，如果該報(bào)文丟失，服務(wù)器端會(huì)超時(shí)重傳之前的FIN報(bào)文，保證服務(wù)器端進(jìn)入正常的CLOSED狀態(tài)。
（2）2MSL后，本連接中的所有報(bào)文就會(huì)從網(wǎng)絡(luò)中消失，防止已失效請(qǐng)求造成異常。

??四、TCP和UDP的區(qū)別

1、TCP是面向連接的，發(fā)送數(shù)據(jù)之前必須建立連接，發(fā)送某些預(yù)備報(bào)文段；UDP是無連接的，發(fā)送數(shù)據(jù)之前不需要建立連接。
2、TCP連接是點(diǎn)對(duì)點(diǎn)的，只支持單個(gè)發(fā)送方和單個(gè)接收方的連接；UDP支持一對(duì)一、一對(duì)多和多對(duì)多通信。
3、TCP提供可靠的交付服務(wù)，通過TCP傳送的數(shù)據(jù)無差錯(cuò)、不丟失、不重復(fù)，按序到達(dá)；UDP適用盡最大努力交付，不保證可靠性，主機(jī)不需要維持復(fù)雜的連接狀態(tài)。
4、TCP是面向字節(jié)流的，TCP不保證接收方的數(shù)據(jù)塊和發(fā)送方數(shù)據(jù)塊大小對(duì)應(yīng)，但接收方的字節(jié)流必須保證和發(fā)送方的字節(jié)流完全一樣。應(yīng)用程序必須有能力識(shí)別收到的字節(jié)流，把它還原成應(yīng)用層數(shù)據(jù)。UDP面向報(bào)文，對(duì)應(yīng)用層添加首部后就交付IP層。

總結(jié)：TCP是面向連接的，點(diǎn)對(duì)點(diǎn)的，可靠的字節(jié)流服務(wù)；UDP是面向無連接的，支持一對(duì)一、一對(duì)多、多對(duì)多通信的，不可靠的數(shù)據(jù)報(bào)服務(wù)。

??五、HTTP 和 HTTPS的區(qū)別（農(nóng)+1）

1、HTTP是互聯(lián)網(wǎng)上應(yīng)用最為廣泛的一種網(wǎng)絡(luò)協(xié)議，是一個(gè)客戶端和服務(wù)器端請(qǐng)求和應(yīng)答的標(biāo)準(zhǔn)，用于從WWW服務(wù)器傳輸超文本到本地瀏覽器的傳輸協(xié)議。（它可以使瀏覽器更加高效，使網(wǎng)絡(luò)傳輸減少）
2、HTTPS是以安全為目標(biāo)的HTTP通道，即在HTTP傳輸上增加了SSL安全套接字層，通過機(jī)密性、數(shù)據(jù)完整性、身份鑒別為HTTP事務(wù)提供安全保證。
3、HTTPS過程
（1）客戶端使用https的URL訪問Web服務(wù)器，要求與Web服務(wù)器建立SSL連接。
（2）Web服務(wù)器收到客戶端請(qǐng)求后，會(huì)講將網(wǎng)站的證書信息（證書包含公鑰）傳送一份給客戶端。
（3）客戶端瀏覽器與Web服務(wù)器開始協(xié)商SSL連接的安全等級(jí)，也就是信息的加密等級(jí)。
（4）瀏覽器根據(jù)雙方同意的安全等級(jí)，建立會(huì)話密鑰，然后利用網(wǎng)站的公鑰將會(huì)話密鑰加密，并傳送給網(wǎng)站。
（5）Web服務(wù)器利用自己的私鑰解密出會(huì)話密鑰。
（6）Web服務(wù)器利用會(huì)話密鑰加密與客戶端之間的通信。
4、 http和https的區(qū)別

• https協(xié)議需要到CA（Certificate Authority，證書頒發(fā)機(jī)構(gòu)）申請(qǐng)證書，一般免費(fèi)證書較少，因而需要一定費(fèi)用。
• http是超文本傳輸協(xié)議，信息是明文傳輸，https則是具有安全性的ssl加密傳輸協(xié)議。
• http和https使用的是完全不同的連接方式，用的端口也不一樣，前者是80，后者是443。
• http的連接很簡(jiǎn)單，是無狀態(tài)的。Https協(xié)議是由SSL+Http協(xié)議構(gòu)建的可進(jìn)行加密傳輸、身份認(rèn)證的網(wǎng)絡(luò)協(xié)議，比http協(xié)議安全。(無狀態(tài)的意思是其數(shù)據(jù)包的發(fā)送、傳輸和接收都是相互獨(dú)立的。無連接的意思是指通信雙方都不長(zhǎng)久的維持對(duì)方的任何信息。)

??六、 TCP的擁塞控制（農(nóng)+1）

• 擁塞控制：在某段時(shí)間內(nèi)，對(duì)某一資源的需求超過了該資源可提供的可用部分，網(wǎng)絡(luò)性能將變壞，這種情況就叫做網(wǎng)絡(luò)擁塞。若出現(xiàn)擁塞而不控制，網(wǎng)絡(luò)的吞吐量將隨輸入負(fù)荷的增大而下降。擁塞控制是減少注入網(wǎng)絡(luò)中的數(shù)據(jù)，減輕路由器和鏈路的負(fù)擔(dān)。這是一個(gè)全局性的問題，設(shè)計(jì)網(wǎng)絡(luò)中所有主機(jī)和路由器，而流量控制是一個(gè)端到端的問題。
• RTT表示從發(fā)送端發(fā)送數(shù)據(jù)開始，到發(fā)送端收到來自接收端的確認(rèn)（接收端收到數(shù)據(jù)后便立即發(fā)送確認(rèn)，不包含數(shù)據(jù)傳輸時(shí)間）總共經(jīng)歷的時(shí)間。

TCP擁塞控制算法：慢啟動(dòng)，擁塞避免，快恢復(fù)，快重傳
原理請(qǐng)觀看視頻

• 慢啟動(dòng)：在TCP雙方建立連接關(guān)系時(shí)，擁塞窗口cwnd被設(shè)置為1，還需設(shè)置慢開始門限ssthresh。每經(jīng)過一個(gè)RTT往返時(shí)間，擁塞窗口的值就會(huì)翻倍，發(fā)送速率也會(huì)翻倍。當(dāng)擁塞窗口的值達(dá)到慢開始門限時(shí)，停止慢啟動(dòng)算法，轉(zhuǎn)而開始擁塞避免算法
• 擁塞避免算法：當(dāng)擁塞避免算法開始后，每經(jīng)過一個(gè)RTT往返時(shí)間即將擁塞窗口的值線性加1，直到發(fā)生報(bào)文段丟失，超時(shí)重傳的情況，則發(fā)送方將慢開始的門限調(diào)整為發(fā)生超時(shí)重傳窗口值的一半，并將cwnd設(shè)置為1，重新開始慢啟動(dòng)算法。

有的時(shí)候報(bào)文段丟失并不是因?yàn)榫W(wǎng)絡(luò)擁塞，發(fā)送方將其認(rèn)定為網(wǎng)絡(luò)擁塞容將降低傳輸效率，此時(shí)可以通過快重傳和快恢復(fù)解決這個(gè)問題

• 快重傳：快重傳要求服務(wù)器收到客戶端發(fā)送的數(shù)據(jù)后立即發(fā)送確認(rèn)，即使收到了失序的報(bào)文段時(shí)也要立即發(fā)出對(duì)已收到報(bào)文段的重復(fù)確認(rèn)。發(fā)送方一旦收到3個(gè)連續(xù)的重復(fù)確認(rèn)，即將相應(yīng)的報(bào)文段立即重傳，而不是等該報(bào)文的超時(shí)重傳計(jì)時(shí)器超時(shí)再重傳。
• 快恢復(fù)：發(fā)送方在執(zhí)行快重傳的同時(shí)，將慢開始門限和擁塞窗口值改為當(dāng)前窗口值的一半，并開始執(zhí)行擁塞避免算法。

??七、滑動(dòng)窗口

滑動(dòng)窗口以字節(jié)為單位。發(fā)送端有一個(gè)發(fā)送窗口，窗口中的序號(hào)是允許發(fā)送的序號(hào)，窗口后沿是以發(fā)送且確認(rèn)的序號(hào)，窗口前沿是不允許發(fā)送的序號(hào)。沒有收到確認(rèn)時(shí)，窗口不會(huì)移動(dòng)。當(dāng)收到確認(rèn)的序號(hào)，即窗口向前移動(dòng)，將已確認(rèn)的序號(hào)置于窗口的后沿。發(fā)送端可以根據(jù)自己的狀況調(diào)整滑動(dòng)窗口大小，從而控制發(fā)送端的接收，進(jìn)行流量控制。

?? 八、HTTP請(qǐng)求中，GET和POST的區(qū)別

• GET請(qǐng)求：向服務(wù)器請(qǐng)求特定資源，并獲取返回實(shí)體主體
• POST請(qǐng)求：向服務(wù)器提交數(shù)據(jù)處理請(qǐng)求，將請(qǐng)求數(shù)據(jù)放在請(qǐng)求報(bào)文主體中，該請(qǐng)求可能導(dǎo)致新的資源建立或已有資源的更改
• POST請(qǐng)求：
  （1）GET是從服務(wù)器上獲取數(shù)據(jù)，POST是向服務(wù)器傳送數(shù)據(jù)。
  （2）GET請(qǐng)求的數(shù)據(jù)會(huì)暴露在地址中，而POST將請(qǐng)求的數(shù)據(jù)放在請(qǐng)求報(bào)文主體中。
  （3）GET限制最多提交2k數(shù)據(jù)，而POST對(duì)于提交的數(shù)據(jù)量沒有限制
  （4）GET請(qǐng)求只能進(jìn)行URL編碼，而POST請(qǐng)求編碼方式?jīng)]有限制
  （5）GET產(chǎn)生一個(gè)TCP數(shù)據(jù)包，瀏覽器會(huì)將http header和data一起發(fā)送過去，服務(wù)器返回200；POS產(chǎn)生兩個(gè)TCP數(shù)據(jù)包，瀏覽器先發(fā)送header，服務(wù)器響應(yīng)100 continue，瀏覽器再發(fā)送data，服務(wù)器返回200
  （6）GET在瀏覽器回退時(shí)是無害的，而POST會(huì)再次提交請(qǐng)求

以下情況最好使用POST：

• 向服務(wù)器發(fā)送大量數(shù)據(jù)
• 無法使用緩存文件
• 發(fā)送包含未知字符的用戶輸入