大家好管闷，我是溫大大
最近溫大大又又又整理了：萬字網(wǎng)絡(luò)協(xié)議方面的總結(jié)
主要覆蓋：網(wǎng)絡(luò)基礎(chǔ)、TCP/UDP 高頻面試題窃肠、HTTP 協(xié)議包个、Cookis/session、滑動窗口機(jī)制等知識點(diǎn)冤留。
這次「網(wǎng)絡(luò)八股文」配合前兩次
這樣同學(xué)們的基礎(chǔ)八股文算是覆蓋全了：數(shù)據(jù)庫碧囊、Linux、網(wǎng)絡(luò)就像湊齊七龍珠能召喚1個(gè)神龍?jiān)S愿1個(gè)愿望一樣纤怒，如果你好好的閱讀下溫大大這三篇文章糯而，保證你能實(shí)現(xiàn)「漲薪」愿望呀。
溫大大的肝算是快到爆穿了泊窘，只求各位同學(xué)幫忙一鍵三連：點(diǎn)贊熄驼、在看、轉(zhuǎn)發(fā)
目錄
網(wǎng)絡(luò)分層基礎(chǔ)
0.1 OSI七層模型 與 TCP五層模型
0.2 五層模型 vs 網(wǎng)絡(luò)協(xié)議有哪些州既？
0.3 什么是面向有連接 vs 面向無連接谜洽？
0.4 UDP和TCP的區(qū)別是什么萝映？
0.5 TCP對應(yīng)的應(yīng)用層協(xié)議有哪些吴叶？
0.6 UDP對應(yīng)的應(yīng)用層協(xié)議有哪些？
TCP 高頻面試題
1.1 TCP 三次握手（快速理解）
1.2 TCP 三次握手（深度理解）
1.3 TCP 兩次握手可以嗎序臂？
1.4 TCP 四次揮手（快速理解）
1.5 TCP 四次揮手（深度理解）
1.6 TCP 第四次揮手為什么要等待2MSL蚌卤？
HTTP 協(xié)議
2.1 HTTP協(xié)議的特點(diǎn)实束？
2.2 HTTP報(bào)文格式
2.3 HTTP狀態(tài)碼有哪些？
2.4 HTTPPOST和GET的區(qū)別逊彭？
2.5 HTTP長連接和短連接咸灿？
2.6 HTTP1.1和 HTTP2.0的區(qū)別？
2.7 HTTPS 與HTTP的區(qū)別侮叮？
2.8 HTTPS 原理（開始理解）
2.9 HTTPS 原理（深入理解）
傳輸 & 解析
3.1 什么是數(shù)字證書避矢？
3.2 DNS 的解析過程？
3.3 瀏覽器中輸入U(xiǎn)RL返回頁面過程囊榜？
3.4 什么是對稱加密和非對稱加密审胸？
緩存技術(shù)
4.1 什么是cookie和session？
4.2 Cookie和Session的區(qū)別卸勺？
網(wǎng)絡(luò)異常處理
5.1 滑動窗口機(jī)制
5.2 詳細(xì)講一下?lián)砣刂疲?/p>
5.3 擁塞避免
5.4 快重傳
5.5 快恢復(fù)
0. 網(wǎng)絡(luò)分層基礎(chǔ)
0.1 OSI七層模型 與 TCP五層模型
OSI七層模型：
應(yīng)用層：為應(yīng)用程序提供網(wǎng)絡(luò)服務(wù)砂沛；
表示層：數(shù)據(jù)格式轉(zhuǎn)換、數(shù)據(jù)壓縮和數(shù)據(jù)加密曙求；
會話層：建立碍庵、斷開和維護(hù)通信鏈接；
傳輸層：為上層協(xié)議提供端到端的可靠傳輸悟狱；
網(wǎng)絡(luò)層：尋址和路由静浴；
數(shù)據(jù)鏈路層：定義通過通信媒介互連的設(shè)備之間傳輸?shù)囊?guī)范；
物理層：利用物理傳輸介質(zhì)為數(shù)據(jù)鏈路層提供物理連接挤渐。
TCP五層模型：
相比OSI七層模型马绝，將OSI的應(yīng)用層、表示層和會話層合為一層：應(yīng)用層挣菲，其他不變富稻。
0.2 五層模型 vs 網(wǎng)絡(luò)協(xié)議有哪些？
0.3 什么是面向有連接 vs 面向無連接
面向有連接
傳輸：會話建立白胀、傳輸數(shù)據(jù)和會話斷開
傳輸可靠性包括：超時(shí)重傳椭赋、流量控制等
常見協(xié)議：TCP
面向無連接型
傳輸：僅提供基本的傳輸數(shù)據(jù)的功能，即使接收端不存在或杠，
發(fā)送端也能發(fā)送數(shù)據(jù)包哪怔，
常見協(xié)議：UDP、IP向抢。
0.4 UDP和TCP的區(qū)別是什么认境？
相同：
UDP和TCP都是傳輸層的協(xié)議
區(qū)別：
TCP是面向有連接型，UDP是面向無連接型挟鸠；
TCP是一對一傳輸叉信，UDP支持一對一、一對多艘希、多對一和多對多的交互通信硼身；
TCP是面向字節(jié)流的硅急，即把應(yīng)用層傳來的報(bào)文看成字節(jié)流，將字節(jié)流拆分成大小不等的數(shù)據(jù)塊佳遂，并添加TCP首部营袜；UDP是面向報(bào)文的，對應(yīng)用層傳下來的報(bào)文不拆分也不合并丑罪，僅添加UDP首部荚板；
TCP支持傳輸可靠性的多種措施，包括保證包的傳輸順序吩屹、重發(fā)機(jī)制啸驯、流量控制和擁塞控制；
UDP僅提供最基本的數(shù)據(jù)傳輸能力祟峦。
0.5 TCP對應(yīng)的應(yīng)用層協(xié)議有哪些罚斗？
FTP：文件傳輸協(xié)議；
SSH：遠(yuǎn)程登錄協(xié)議宅楞；
HTTP：web服務(wù)器傳輸超文本到本地瀏覽器的超文本傳輸協(xié)議针姿。
UDP對應(yīng)的典型的應(yīng)用層協(xié)議：
0.6 UDP對應(yīng)的應(yīng)用層協(xié)議有哪些？
DNS：域名解析協(xié)議厌衙；
TFTP：簡單文件傳輸協(xié)議距淫；
SNMP：簡單網(wǎng)絡(luò)管理協(xié)議。
1. TCP 高頻面試題
1.1 TCP 三次握手（快速理解）
A向B發(fā)起建立連接請求：A——>B婶希；
B收到A的發(fā)送信號榕暇，并且向A發(fā)送確認(rèn)信息：B——>A；
A收到B的確認(rèn)信號喻杈，并向B發(fā)送確認(rèn)信號：A——>B彤枢。
三次握手大概就是這么個(gè)過程。
通過第一次握手筒饰，B知道A能夠發(fā)送數(shù)據(jù)缴啡。
通過第二次握手，A知道B能發(fā)送數(shù)據(jù)瓷们。
結(jié)合第一次握手和第二次握手业栅，A知道B能接收數(shù)據(jù)。
結(jié)合第三次握手谬晕，B知道A能夠接收數(shù)據(jù)碘裕。
至此，完成了握手過程攒钳，A知道B能收能發(fā)帮孔，B知道A能收能發(fā)，通信連接至此建立夕玩。
三次連接是保證可靠的最小握手次數(shù)你弦，再多次握手也不能提高通信成功的概率，反而浪費(fèi)資源燎孟。
1.2 TCP 三次握手（深度理解）
備注：
A 代表 客戶端
B 代表 服務(wù)端
第一次握手：
A 向 B 發(fā)起建立連接請求禽作，A 會隨機(jī)生成一個(gè)起始序列號x
A 向 B 發(fā)送的字段中包含標(biāo)志位SYN=1，序列號seq=x
第一次握手前A 的狀態(tài)為CLOSE
第一次握手后A 的狀態(tài)為SYN-SENT
此時(shí) B 的狀態(tài)為LISTEN
總結(jié)：A 發(fā) （SYN=1,seq=x）到 B
第二次握手：
B 在收到A發(fā)來的報(bào)文后揩页，會隨機(jī)生成一個(gè)B 的起始序列號y旷偿，
然后給客戶端回復(fù)一段報(bào)文，其中包括標(biāo)志位SYN=1爆侣，ACK=1萍程，序列號seq=y，確認(rèn)號ack=x+1兔仰。
第二次握手前服務(wù)端的狀態(tài)為LISTEN茫负，第二次握手后服務(wù)端的狀態(tài)為SYN-RCVD，此時(shí)客戶端的狀態(tài)為SYN-SENT乎赴。（其中SYN=1表示要和客戶端建立一個(gè)連接忍法，ACK=1表示確認(rèn)序號有效）
總結(jié)：B 發(fā)（SYN=1, ACK=1, seq=y, ack=x+1）到 A
第三次握手：
A 收到 B 發(fā)來的報(bào)文后，會再向B發(fā)送報(bào)文榕吼，
其中包含標(biāo)志位ACK=1饿序，序列號seq=x+1，確認(rèn)號ack=y+1羹蚣。
第三次握手前客戶端的狀態(tài)為SYN-SENT原探，第三次握手后客戶端和服務(wù)端的狀態(tài)都為ESTABLISHED。
此時(shí)連接建立完成顽素。
總結(jié)：A 發(fā)（ACK=1, seq=x+1, ack=y+1）到 B
1.3 TCP 兩次握手可以嗎咽弦？
不可以。
防止已失效的連接請求報(bào)文段突然又傳輸?shù)搅朔?wù)端胁出，導(dǎo)致產(chǎn)生問題离唬。
比如客戶端A發(fā)出連接請求，可能因?yàn)榫W(wǎng)絡(luò)阻塞原因划鸽，A沒有收到確認(rèn)報(bào)文输莺，于是A再重傳一次連接請求。
連接成功裸诽，等待數(shù)據(jù)傳輸完畢后嫂用，就釋放了連接。
然后A發(fā)出的第一個(gè)連接請求等到連接釋放以后的某個(gè)時(shí)間才到達(dá)服務(wù)端B丈冬，此時(shí)B誤認(rèn)為A又發(fā)出一次新的連接請求嘱函，于是就向A發(fā)出確認(rèn)報(bào)文段。
1.4 TCP 四次揮手（快速理解）
那為什么需要四次揮手呢埂蕊？請看如下過程：
A向B發(fā)起請求往弓，表示A沒有數(shù)據(jù)要發(fā)送了：A——>B疏唾；
B向A發(fā)送信號，確認(rèn)A的斷開請求：B——>A函似；
B向A發(fā)送信號槐脏，請求斷開連接，表示B沒有數(shù)據(jù)要發(fā)送了：B——>A撇寞；
A向B發(fā)送確認(rèn)信號顿天，同意斷開：A——>B。
B收到確認(rèn)信號蔑担，斷開連接牌废，而A在一段時(shí)間內(nèi)沒收到B的信號，表明B已經(jīng)斷開了啤握，于是A也斷開了連接鸟缕。至此，完成揮手過程排抬。
可能有捧油會問叁扫，為什么2、3次揮手不能合在一次揮手中畜埋？那是因?yàn)榇藭r(shí)A雖然不再發(fā)送數(shù)據(jù)了莫绣，但是還可以接收數(shù)據(jù)，B可能還有數(shù)據(jù)要發(fā)送給A悠鞍，所以兩次揮手不能合并為一次对室。
揮手次數(shù)比握手多一次，是因?yàn)槲帐诌^程咖祭，通信只需要處理連接掩宜。而揮手過程，通信需要處理數(shù)據(jù)+連接么翰。
1.5 TCP 四次揮手（深度理解）
A的應(yīng)用進(jìn)程先向其TCP發(fā)出連接釋放報(bào)文段（FIN=1牺汤，seq=u），并停止再發(fā)送數(shù)據(jù)浩嫌，主動關(guān)閉TCP連接檐迟，進(jìn)入FIN-WAIT-1（終止等待1）狀態(tài)，等待B的確認(rèn)码耐。
B收到連接釋放報(bào)文段后即發(fā)出確認(rèn)報(bào)文段（ACK=1追迟，ack=u+1，seq=v）骚腥，B進(jìn)入CLOSE-WAIT（關(guān)閉等待）狀態(tài)敦间，此時(shí)的TCP處于半關(guān)閉狀態(tài)，A到B的連接釋放。
A收到B的確認(rèn)后廓块，進(jìn)入FIN-WAIT-2（終止等待2）狀態(tài)厢绝，等待B發(fā)出的連接釋放報(bào)文段。
B發(fā)送完數(shù)據(jù)带猴，就會發(fā)出連接釋放報(bào)文段（FIN=1昔汉，ACK=1，seq=w浓利，ack=u+1）挤庇，B進(jìn)入LAST-ACK（最后確認(rèn)）狀態(tài)钞速，等待A的確認(rèn)贷掖。
A收到B的連接釋放報(bào)文段后，對此發(fā)出確認(rèn)報(bào)文段（ACK=1渴语，seq=u+1苹威，ack=w+1），A進(jìn)入TIME-WAIT（時(shí)間等待）狀態(tài)驾凶。此時(shí)TCP未釋放掉牙甫，需要經(jīng)過時(shí)間等待計(jì)時(shí)器設(shè)置的時(shí)間2MSL（最大報(bào)文段生存時(shí)間）后，A才進(jìn)入CLOSED狀態(tài)调违。B收到A發(fā)出的確認(rèn)報(bào)文段后關(guān)閉連接窟哺，若沒收到A發(fā)出的確認(rèn)報(bào)文段，B就會重傳連接釋放報(bào)文段技肩。
1.6 TCP 第四次揮手為什么要等待2MSL且轨？
保證A發(fā)送的最后一個(gè)ACK報(bào)文段能夠到達(dá)B。
這個(gè)ACK報(bào)文段有可能丟失虚婿，B收不到這個(gè)確認(rèn)報(bào)文旋奢，就會超時(shí)重傳連接釋放報(bào)文段，然后A可以在2MSL時(shí)間內(nèi)收到這個(gè)重傳的連接釋放報(bào)文段然痊，接著A重傳一次確認(rèn)至朗，重新啟動2MSL計(jì)時(shí)器，最后A和B都進(jìn)入到CLOSED狀態(tài)剧浸，若A在TIME-WAIT狀態(tài)不等待一段時(shí)間锹引，而是發(fā)送完ACK報(bào)文段后立即釋放連接，則無法收到B重傳的連接釋放報(bào)文段唆香，所以不會再發(fā)送一次確認(rèn)報(bào)文段粤蝎，B就無法正常進(jìn)入到CLOSED狀態(tài)。
防止已失效的連接請求報(bào)文段出現(xiàn)在本連接中袋马。
A在發(fā)送完最后一個(gè)ACK報(bào)文段后初澎，再經(jīng)過2MSL，就可以使這個(gè)連接所產(chǎn)生的所有報(bào)文段都從網(wǎng)絡(luò)中消失，使下一個(gè)新的連接中不會出現(xiàn)舊的連接請求報(bào)文段碑宴。
2. HTTP 協(xié)議
2.1 HTTP協(xié)議的特點(diǎn)软啼？
HTTP允許傳輸任意類型的數(shù)據(jù)。傳輸?shù)念愋陀蒀ontent-Type加以標(biāo)記延柠。
無狀態(tài)祸挪。對于客戶端每次發(fā)送的請求，服務(wù)器都認(rèn)為是一個(gè)新的請求贞间，上一次會話和下一次會話之間沒有聯(lián)系贿条。
支持客戶端/服務(wù)器模式。
2.2 HTTP報(bào)文格式
HTTP請求由請求行增热、請求頭部整以、空行和請求體四個(gè)部分組成。
請求行：包括請求方法峻仇，訪問的資源URL公黑，使用的HTTP版本。GET和POST是最常見的HTTP方法摄咆，除此以外還包括DELETE凡蚜、HEAD、OPTIONS吭从、PUT朝蜘、TRACE。
請求頭：格式為“屬性名:屬性值”涩金，服務(wù)端根據(jù)請求頭獲取客戶端的信息谱醇，主要有cookie、host鸭廷、connection枣抱、accept-language、accept-encoding辆床、user-agent佳晶。
請求體：用戶的請求數(shù)據(jù)如用戶名，密碼等讼载。
2.3 HTTP狀態(tài)碼有哪些轿秧？
2.4 HTTP POST和GET的區(qū)別？
GET請求參數(shù)通過URL傳遞咨堤，POST的參數(shù)放在請求體中菇篡。
GET產(chǎn)生一個(gè)TCP數(shù)據(jù)包；POST產(chǎn)生兩個(gè)TCP數(shù)據(jù)包一喘。對于GET方式的請求驱还，瀏覽器會把請求頭和請求體一并發(fā)送出去嗜暴；而對于POST，瀏覽器先發(fā)送請求頭议蟆，服務(wù)器響應(yīng)100 continue闷沥，瀏覽器再發(fā)送請求體。
GET請求會被瀏覽器主動緩存咐容，而POST不會舆逃，除非手動設(shè)置。
GET請求只能進(jìn)行url編碼戳粒，而POST支持多種編碼方式路狮。
GET請求參數(shù)會被完整保留在瀏覽器歷史記錄里，而POST中的參數(shù)不會被保留蔚约。
2.5 HTTP 長連接和短連接奄妨？
短連接
連接->傳輸數(shù)據(jù)->關(guān)閉連接
比如HTTP是無狀態(tài)的的短鏈接，瀏覽器和服務(wù)器每進(jìn)行一次HTTP操作炊琉，就建立一次連接展蒂，但任務(wù)結(jié)束就中斷連接又活。
因?yàn)檫B接后接收了數(shù)據(jù)就斷開了苔咪，所以每次數(shù)據(jù)接受處理不會有聯(lián)系。 這也是HTTP協(xié)議無狀態(tài)的原因之一柳骄。
長連接
連接->傳輸數(shù)據(jù)->保持連接 -> 傳輸數(shù)據(jù)-> ...........->直到一方關(guān)閉連接团赏，多是客戶端關(guān)閉連接。
長連接指建立SOCKET連接后不管是否使用都保持連接耐薯，但安全性較差舔清。
長鏈接使用場景
長連接多用于操作頻繁，點(diǎn)對點(diǎn)的通訊曲初，而且連接數(shù)不能太多情況体谒。每個(gè)TCP連接都需要三步握手，
這需要時(shí)間臼婆，如果每個(gè)操作都是先連接抒痒，再操作的話那么處理速度會降低很多，所以每個(gè)操作完后都
不斷開颁褂，次處理時(shí)直接發(fā)送數(shù)據(jù)包就OK了故响，不用建立TCP連接。例如：數(shù)據(jù)庫的連接用長連接颁独， 如果用短連接頻繁的通信會造成socket錯(cuò)誤彩届，而且頻繁的socket 創(chuàng)建也是對資源的浪費(fèi)。
短鏈接使用場景
而像WEB網(wǎng)站的http服務(wù)一般都用短鏈接誓酒，因?yàn)殚L連接對于服務(wù)端來說會耗費(fèi)一定的資源樟蠕，
而像WEB網(wǎng)站這么頻繁的成千上萬甚至上億客戶端的連接用短連接會更省一些資源，如果用長連接，而且同時(shí)有成千上萬的用戶寨辩，如果每個(gè)用戶都占用一個(gè)連接的話寂汇，那可想而知吧。所以并發(fā)量大捣染，但每個(gè)用戶無需頻
繁操作情況下需用短連好骄瓣。
2.6 HTTP 1.1和 HTTP2.0的區(qū)別？
區(qū)別1: 解析協(xié)議不同
http1 協(xié)議解析 基于文本解析
http2.0 協(xié)議解析 基于二進(jìn)制
區(qū)別2: HTTP2.0 采用多路復(fù)用(Mutiplexing)
一個(gè)連接上可以有多個(gè)request,且可以隨機(jī)的混在一起,每個(gè)不同的request都有對應(yīng)的id,服務(wù)端可以通過request_id來辨別,大大加快了傳輸速率
區(qū)別3: http2.0 header壓縮:
http1.x中的header需要攜帶大量信息.而且每次都要重復(fù)發(fā)送.
http2.0使用encode來減少傳輸?shù)膆eader大小.而且客戶端和服務(wù)端可以各自緩存(cache)一份header filed表,避免了header的重復(fù)傳輸,還可以減少傳輸?shù)拇笮?
服務(wù)端推送(server push): 可以通過解析html中的依賴,只能的返回所需的其他文件(css或者js等),而不用再發(fā)起一次請求.
區(qū)別4: http2.0 服務(wù)端推送(server push):
可以通過解析html中的依賴,只能的返回所需的其他文件(css或者js等),而不用再發(fā)起一次請求.
2.7 HTTPS 與HTTP 的區(qū)別耍攘？
HTTP 明文傳輸榕栏，安全性較差，HTTPS 加密傳輸蕾各，安全性較好扒磁。
HTTPS 協(xié)議需要到 CA（Certificate Authority，數(shù)字證書認(rèn)證機(jī)構(gòu)） 申請證書式曲，一般免費(fèi)證書較少妨托，因而需要一定費(fèi)用。
HTTP 頁面響應(yīng)速度比 HTTPS 快吝羞，主要是因?yàn)?HTTP 使用 TCP 三次握手建立連接兰伤，客戶端和服務(wù)器需要交換 3 個(gè)包，而 HTTPS除了 TCP 的三個(gè)包钧排，還要加上 ssl 握手需要的 9 個(gè)包敦腔，所以一共是 12 個(gè)包。
HTTP 和 HTTP 使用的是完全不同的連接方式恨溜，用的端口也不一樣符衔，前者是 80，后者是 443糟袁。
HTTPS 其實(shí)就是建構(gòu)在 SSL/TLS 之上的 HTTP 協(xié)議判族，所以，要比較 HTTPS 比 HTTP 要更耗費(fèi)服務(wù)器資源项戴。
2.8 HTTPS 原理（快速理解）
HTTPS 默認(rèn)工作在 TCP 協(xié)議443端口形帮，它的工作流程一般如以下方式：
1、TCP 三次同步握手
2肯尺、客戶端驗(yàn)證服務(wù)器數(shù)字證書
3沃缘、DH 算法協(xié)商對稱加密算法的密鑰、hash 算法的密鑰
4则吟、SSL 安全加密隧道協(xié)商完成
5槐臀、網(wǎng)頁以加密的方式傳輸，用協(xié)商的對稱加密算法和密鑰加密氓仲，保證數(shù)據(jù)機(jī)密性水慨；用協(xié)商的hash算法進(jìn)行數(shù)據(jù)完整性保護(hù)肌似，保證數(shù)據(jù)不被篡改棺克。
2.9 HTTPS 原理（深入理解）
1辙培、客戶端發(fā)起 HTTPS 請求
這個(gè)沒什么好說的糊闽，就是用戶在瀏覽器里輸入一個(gè) https 網(wǎng)址，然后連接到 server 的 443 端口谍珊。
2治宣、服務(wù)端的配置
采用 HTTPS 協(xié)議的服務(wù)器必須要有一套數(shù)字證書，可以自己制作砌滞，也可以向組織申請侮邀，區(qū)別就是自己頒發(fā)的證書需要客戶端驗(yàn)證通過，才可以繼續(xù)訪問贝润，而使用受信任的公司申請的證書則不會彈出提示頁面(startssl 就是個(gè)不錯(cuò)的選擇绊茧，有 1 年的免費(fèi)服務(wù))。
這套證書其實(shí)就是一對公鑰和私鑰打掘，如果對公鑰和私鑰不太理解华畏，可以想象成一把鑰匙和一個(gè)鎖頭，只是全世界只有你一個(gè)人有這把鑰匙尊蚁，你可以把鎖頭給別人亡笑，別人可以用這個(gè)鎖把重要的東西鎖起來，然后發(fā)給你枝誊，因?yàn)橹挥心阋粋€(gè)人有這把鑰匙况芒，所以只有你才能看到被這把鎖鎖起來的東西惜纸。
3叶撒、傳送證書
這個(gè)證書其實(shí)就是公鑰，只是包含了很多信息耐版，如證書的頒發(fā)機(jī)構(gòu)祠够，過期時(shí)間等等。
4粪牲、客戶端解析證書
這部分工作是有客戶端的TLS來完成的古瓤，首先會驗(yàn)證公鑰是否有效，比如頒發(fā)機(jī)構(gòu)腺阳，過期時(shí)間等等落君，如果發(fā)現(xiàn)異常，則會彈出一個(gè)警告框亭引，提示證書存在問題绎速。
如果證書沒有問題，那么就生成一個(gè)隨機(jī)值焙蚓，然后用證書對該隨機(jī)值進(jìn)行加密纹冤，就好像上面說的洒宝，把隨機(jī)值用鎖頭鎖起來，這樣除非有鑰匙萌京，不然看不到被鎖住的內(nèi)容雁歌。
5、傳送加密信息
這部分傳送的是用證書加密后的隨機(jī)值知残，目的就是讓服務(wù)端得到這個(gè)隨機(jī)值靠瞎，以后客戶端和服務(wù)端的通信就可以通過這個(gè)隨機(jī)值來進(jìn)行加密解密了。
6求妹、服務(wù)端解密信息
服務(wù)端用私鑰解密后较坛，得到了客戶端傳過來的隨機(jī)值(私鑰)，然后把內(nèi)容通過該值進(jìn)行對稱加密扒最，所謂對稱加密就是丑勤，將信息和私鑰通過某種算法混合在一起，這樣除非知道私鑰吧趣，不然無法獲取內(nèi)容法竞，而正好客戶端和服務(wù)端都知道這個(gè)私鑰，所以只要加密算法夠彪悍强挫，私鑰夠復(fù)雜岔霸，數(shù)據(jù)就夠安全。
7俯渤、傳輸加密后的信息
這部分信息是服務(wù)段用私鑰加密后的信息呆细，可以在客戶端被還原。
8八匠、客戶端解密信息
客戶端用之前生成的私鑰解密服務(wù)段傳過來的信息絮爷，于是獲取了解密后的內(nèi)容，整個(gè)過程第三方即使監(jiān)聽到了數(shù)據(jù)梨树，也束手無策坑夯。
3. 傳輸 & 解析
3.1 什么是數(shù)字證書？
簡介
服務(wù)端可以向證書頒發(fā)機(jī)構(gòu)CA申請證書抡四，以避免中間人攻擊（防止證書被篡改）柜蜈。
證書包含三部分內(nèi)容：證書內(nèi)容、證書簽名算法和簽名指巡，簽名是為了驗(yàn)證身份淑履。
服務(wù)端把證書傳輸給瀏覽器，瀏覽器從證書里取公鑰藻雪。證書可以證明該公鑰對應(yīng)本網(wǎng)站秘噪。
制作過程
CA使用證書簽名算法對證書內(nèi)容進(jìn)行hash運(yùn)算。
對hash后的值用CA的私鑰加密阔涉，得到數(shù)字簽名缆娃。
瀏覽器驗(yàn)證過程
獲取證書捷绒，得到證書內(nèi)容、證書簽名算法和數(shù)字簽名贯要。
用CA機(jī)構(gòu)的公鑰對數(shù)字簽名解密（由于是瀏覽器信任的機(jī)構(gòu)暖侨，所以瀏覽器會保存它的公鑰）。
用證書里的簽名算法對證書內(nèi)容進(jìn)行hash運(yùn)算崇渗。
比較解密后的數(shù)字簽名和對證書內(nèi)容做hash運(yùn)算后得到的哈希值字逗，相等則表明證書可信。
3.2 DNS 的解析過程宅广？
瀏覽器搜索自己的DNS緩存
若沒有葫掉，則搜索操作系統(tǒng)中的DNS緩存和hosts文件
若沒有，則操作系統(tǒng)將域名發(fā)送至本地域名服務(wù)器跟狱，本地域名服務(wù)器查詢自己的DNS緩存俭厚，查找成功則返回結(jié)果，否則依次向根域名服務(wù)器驶臊、頂級域名服務(wù)器挪挤、權(quán)限域名服務(wù)器發(fā)起查詢請求，最終返回IP地址給本地域名服務(wù)器
本地域名服務(wù)器將得到的IP地址返回給操作系統(tǒng)关翎，同時(shí)自己也將IP地址緩存起來
操作系統(tǒng)將 IP 地址返回給瀏覽器扛门，同時(shí)自己也將IP地址緩存起來
瀏覽器得到域名對應(yīng)的IP地址
3.3 瀏覽器中輸入U(xiǎn)RL返回頁面過程？
解析域名纵寝，找到主機(jī) IP论寨。
瀏覽器利用 IP 直接與網(wǎng)站主機(jī)通信，三次握手爽茴，建立 TCP 連接葬凳。瀏覽器會以一個(gè)隨機(jī)端口向服務(wù)端的 web 程序 80 端口發(fā)起 TCP 的連接。
建立 TCP 連接后闹啦，瀏覽器向主機(jī)發(fā)起一個(gè)HTTP請求沮明。
服務(wù)器響應(yīng)請求，返回響應(yīng)數(shù)據(jù)窍奋。
瀏覽器解析響應(yīng)內(nèi)容，進(jìn)行渲染酱畅，呈現(xiàn)給用戶琳袄。
3.4 什么是對稱加密和非對稱加密？
對稱加密：通信雙方使用相同的密鑰進(jìn)行加密纺酸。特點(diǎn)是加密速度快窖逗，但是缺點(diǎn)是密鑰泄露會導(dǎo)致密文數(shù)據(jù)被破解。常見的對稱加密有AES和DES算法餐蔬。
非對稱加密：它需要生成兩個(gè)密鑰碎紊，公鑰和私鑰佑附。公鑰是公開的，任何人都可以獲得仗考，而私鑰是私人保管的音同。公鑰負(fù)責(zé)加密，私鑰負(fù)責(zé)解密秃嗜；或者私鑰負(fù)責(zé)加密权均，公鑰負(fù)責(zé)解密。這種加密算法安全性更高锅锨，但是計(jì)算量相比對稱加密大很多叽赊，加密和解密都很慢。常見的非對稱算法有RSA和DSA必搞。
4. 緩存技術(shù)
4.1 什么是cookie和session必指？
什么是Cookie（客戶端技術(shù)）
Cookie實(shí)際上是一小段的文本信息∷≈蓿客戶端請求服務(wù)器取劫，如果服務(wù)器需要記錄該用戶狀態(tài)，就使用response向客戶端瀏覽器頒發(fā)一個(gè)Cookie研侣∑仔埃客戶端會把Cookie保存起來。
當(dāng)瀏覽器再請求該網(wǎng)站時(shí)庶诡，瀏覽器把請求的網(wǎng)址連同該Cookie一同提交給服務(wù)器惦银。服務(wù)器檢查該Cookie，以此來辨認(rèn)用戶狀態(tài)末誓。服務(wù)器還可以根據(jù)需要修改Cookie的內(nèi)容扯俱。
信息保存的時(shí)間可以根據(jù)需要設(shè)置.
如果沒有設(shè)置Cookie失效日期,它們僅保存到關(guān)閉瀏覽器程序?yàn)橹?
如果將Cookie對象的Expires屬性設(shè)置為Minvalue,則表示Cookie永遠(yuǎn)不會過期.
Cookie存儲的數(shù)據(jù)量很受限制,大多數(shù)瀏覽器支持最大容量為4K,因此不要用來保存數(shù)據(jù)集及其他大量數(shù)據(jù).
由于并非所有的瀏覽器都支持Cookie,并且數(shù)據(jù)信息是以明文文本的形式保存在客戶端的計(jì)算機(jī)中,
因此最好不要保存敏感的,未加密的數(shù)據(jù),否則會影響網(wǎng)站的安全性
什么是Session（服務(wù)端技術(shù)）
Session是另一種記錄客戶狀態(tài)的機(jī)制，不同的是Cookie保存在客戶端瀏覽器中喇澡，而Session保存在服務(wù)器上迅栅。客戶端瀏覽器訪問服務(wù)器的時(shí)候晴玖，服務(wù)器把客戶端信息以某種形式記錄在服務(wù)器上读存。這就是Session∨皇海客戶端瀏覽器再次訪問時(shí)只需要從該Session中查找該客戶的狀態(tài)就可以了让簿。
每個(gè)用戶訪問服務(wù)器都會建立一個(gè)session，那服務(wù)器是怎么標(biāo)識用戶的唯一身份呢秀睛？事實(shí)上尔当，用戶與服務(wù)器建立連接的同時(shí)，服務(wù)器會自動為其分配一個(gè)SessionId蹂安。
4.2 Cookie和Session的區(qū)別椭迎？
1锐帜、數(shù)據(jù)存儲位置：cookie數(shù)據(jù)存放在客戶的瀏覽器上，session數(shù)據(jù)放在服務(wù)器上畜号。
2缴阎、安全性：cookie不是很安全，別人可以分析存放在本地的cookie并進(jìn)行cookie欺騙弄兜，考慮到安全應(yīng)當(dāng)使用session药蜻。
3、服務(wù)器性能：session會在一定時(shí)間內(nèi)保存在服務(wù)器上替饿。當(dāng)訪問增多语泽，會比較占用你服務(wù)器的性能，考慮到減輕服務(wù)器性能方面视卢，應(yīng)當(dāng)使用cookie踱卵。
4、數(shù)據(jù)大芯莨：單個(gè)cookie保存的數(shù)據(jù)不能超過4K惋砂，很多瀏覽器都限制一個(gè)站點(diǎn)最多保存20個(gè)cookie。
5绳锅、信息重要程度：可以考慮將登陸信息等重要信息存放為session西饵，其他信息如果需要保留，可以放在cookie中鳞芙。
5. 網(wǎng)絡(luò)異常處理
5.1 滑動窗口機(jī)制
在TCP協(xié)議當(dāng)中窗口機(jī)制分為兩種：
1.固定的窗口大小
2.滑動窗口
固定窗口存在的問題
我們假設(shè)這個(gè)固定窗口的大小為1眷柔，也就是每次只能發(fā)送一個(gè)數(shù)據(jù)，只有接收方對這個(gè)數(shù)據(jù)進(jìn)行了確認(rèn)后才能發(fā)送第二個(gè)數(shù)據(jù)原朝。在圖中我們可以看到驯嘱，發(fā)送方每發(fā)送一個(gè)數(shù)據(jù)接收方就要給發(fā)送方一個(gè)ACK對這個(gè)數(shù)據(jù)進(jìn)行確認(rèn)。只有接收了這個(gè)確認(rèn)數(shù)據(jù)以后發(fā)送方才能傳輸下個(gè)數(shù)據(jù)喳坠。
存在的問題：如果窗口過小鞠评，當(dāng)傳輸比較大的數(shù)據(jù)的時(shí)候需要不停的對數(shù)據(jù)進(jìn)行確認(rèn)，這個(gè)時(shí)候就會造成很大的延遲壕鹉。
如果窗口過大剃幌，我們假設(shè)發(fā)送方一次發(fā)送100個(gè)數(shù)據(jù)，但接收方只能處理50個(gè)數(shù)據(jù)御板，這樣每次都只對這50個(gè)數(shù)據(jù)進(jìn)行確認(rèn)锥忿。發(fā)送方下一次還是發(fā)送100個(gè)數(shù)據(jù)，但接受方還是只能處理50個(gè)數(shù)據(jù)怠肋。這樣就避免了不必要的數(shù)據(jù)來擁塞我們的鏈路。
因此淹朋，我們引入了滑動窗口
1.滑動窗口概述
滑動窗口通俗來講就是一種流量控制技術(shù)笙各。
它本質(zhì)上是描述接收方的TCP數(shù)據(jù)報(bào)緩沖區(qū)大小的數(shù)據(jù)钉答，發(fā)送方根據(jù)這個(gè)數(shù)據(jù)來計(jì)算自己最多能發(fā)送多長的數(shù)據(jù)，如果發(fā)送方收到接收方的窗口大小為0的TCP數(shù)據(jù)報(bào)杈抢，那么發(fā)送方將停止發(fā)送數(shù)據(jù)数尿，等到接收方發(fā)送窗口大小不為0的數(shù)據(jù)報(bào)的到來
2.工作原理
第一次發(fā)送數(shù)據(jù)這個(gè)時(shí)候的窗口大小是根據(jù)鏈路帶寬的大小來決定的。
假設(shè)這時(shí)候的窗口是3.這個(gè)時(shí)候接收方收到數(shù)據(jù)以后會對數(shù)據(jù)進(jìn)行確認(rèn)告訴哦發(fā)送方我下次希望收到的數(shù)據(jù)是多少惶楼。
在上圖中：我們看到接收方發(fā)送的ACK = 3（這是對發(fā)送方發(fā)送序列2的回答確認(rèn)右蹦，下一次接收方期望接收到的是3序列信號），這個(gè)時(shí)候發(fā)送方收到這個(gè)數(shù)據(jù)以后就知道我第一次發(fā)送的3個(gè)數(shù)據(jù)對方只收到了兩個(gè)歼捐，就知道第三個(gè)數(shù)據(jù)對方?jīng)]有收到何陆，下次返送的時(shí)候就從第3個(gè)數(shù)據(jù)開始發(fā)。這時(shí)候窗口大小就變?yōu)榱?.
看到接收方發(fā)送的ACK是5就表示他下一次希望收到的數(shù)據(jù)是5豹储，發(fā)送方就知道我剛才發(fā)送的2個(gè)數(shù)據(jù)對方收到了贷盲，這個(gè)時(shí)候開始發(fā)送第5個(gè)數(shù)據(jù)。
當(dāng)鏈路變好或者變差剥扣，這個(gè)窗口還會發(fā)生變化巩剖，并不是第一次協(xié)商好了以后就永遠(yuǎn)不會變化了。
3.死鎖狀態(tài)
（1）概述：
當(dāng)接收端向發(fā)送端發(fā)送零窗口報(bào)文段后不久钠怯，接收端的接收緩存又有了一些存儲空間佳魔，于是接收端向發(fā)送端發(fā)送了Windows size = 2的報(bào)文段，然而這個(gè)報(bào)文段在傳輸過程中丟失了晦炊。發(fā)送端一直等待收到接收端發(fā)送的非零窗口的通知鞠鲜，而接收端一直等待發(fā)送端發(fā)送數(shù)據(jù)，這樣就死鎖了刽锤。
（2）解決方法
TCP為每個(gè)連接設(shè)有一個(gè)持續(xù)計(jì)時(shí)器镊尺。只要TCP連接的一方收到對方的零窗口通知，就啟動持續(xù)計(jì)時(shí)器并思，若持續(xù)計(jì)時(shí)器設(shè)置的時(shí)間到期庐氮，就發(fā)送一個(gè)零窗口探測報(bào)文段（僅攜帶1字節(jié)的數(shù)據(jù)），而對方就在確認(rèn)這個(gè)探測報(bào)文段時(shí)給出了現(xiàn)在的窗口值宋彼。
4.TCP報(bào)文段的發(fā)送時(shí)機(jī)（傳輸效率問題）
可以用以下三種不同的機(jī)制控制TCP報(bào)文段的發(fā)送時(shí)機(jī)：
（1）TCP維持一個(gè)變量MSS弄砍，等于最大報(bào)文段的長度。只要緩沖區(qū)存放的數(shù)據(jù)達(dá)到MSS字節(jié)時(shí)输涕，就組裝成了一個(gè)TCP報(bào)文段發(fā)送出去
（2）由發(fā)送方的應(yīng)用進(jìn)程指明要發(fā)送的報(bào)文段音婶，即：TCP支持推送操作
（3）發(fā)送方的一個(gè)計(jì)時(shí)器期限到了，這時(shí)就把當(dāng)前已有的緩存數(shù)據(jù)裝入報(bào)文段（但長度不能超過MSS）發(fā)送出去莱坎。
5.2 詳細(xì)講一下?lián)砣刂疲?/p>
一衣式、為何要進(jìn)行擁塞控制？
為了方便，我們假設(shè)主機(jī)A給主機(jī)B傳輸數(shù)據(jù)碴卧。
我們知道弱卡，兩臺主機(jī)在傳輸數(shù)據(jù)包的時(shí)候，如果發(fā)送方遲遲沒有收到接收方反饋的ACK住册，那么發(fā)送方就會認(rèn)為它發(fā)送的數(shù)據(jù)包丟失了婶博，進(jìn)而會重新傳輸這個(gè)丟失的數(shù)據(jù)包。
然而實(shí)際情況有可能此時(shí)有太多主機(jī)正在使用信道資源荧飞，導(dǎo)致網(wǎng)絡(luò)擁塞了凡人，而A發(fā)送的數(shù)據(jù)包被堵在了半路，遲遲沒有到達(dá)B叹阔。這個(gè)時(shí)候A誤認(rèn)為是發(fā)生了丟包情況挠轴，會重新傳輸這個(gè)數(shù)據(jù)包。
結(jié)果就是不僅浪費(fèi)了信道資源条获，還會使網(wǎng)絡(luò)更加擁塞忠荞。因此，我們需要進(jìn)行擁塞控制帅掘。
二委煤、如何知道網(wǎng)絡(luò)的擁塞情況？
A 與 B 建立連接之后修档，就可以向B發(fā)送數(shù)據(jù)了碧绞，然而這個(gè)時(shí)候 A 并不知道此時(shí)的網(wǎng)絡(luò)擁塞情況如何，也就是說吱窝，A 不知道一次性連續(xù)發(fā)送多少個(gè)數(shù)據(jù)包好讥邻，我們也把 A 一次性連續(xù)發(fā)送多少個(gè)數(shù)據(jù)包稱之為擁塞窗口，用 N 代表此時(shí)擁塞窗口的大小吧院峡。
為了探測網(wǎng)絡(luò)的擁塞情況兴使，我們可以采取以下兩種策略：
1、先發(fā)送一個(gè)數(shù)據(jù)包試探下照激，如果該數(shù)據(jù)包沒有發(fā)生超時(shí)事件(也就是沒有丟包)发魄。那么下次發(fā)送時(shí)就發(fā)送2個(gè)，如果還是沒有發(fā)生超時(shí)事件俩垃，下次就發(fā)送3個(gè)励幼，以此類推，即N = 1, 2, 3, 4, 5.....
2口柳、一個(gè)一個(gè)增加實(shí)在是太慢了苹粟，所以可以剛開始發(fā)送1個(gè)，如果沒有發(fā)生超時(shí)時(shí)間跃闹，就發(fā)送2個(gè)嵌削，如果還是沒有發(fā)送超時(shí)事件就發(fā)送4個(gè)毛好，接著8個(gè)...，用翻倍的速度類推,即 N = 1, 2, 4, 8, 16...
無論是第一種方法還是第二種方法掷贾，最后都會出現(xiàn)瓶頸值睛榄。不過這里值得注意的是荣茫，第一種情況的增長速率確實(shí)有點(diǎn)慢想帅，但是第二種情況以指數(shù)增長，增長速度有點(diǎn)太快了啡莉，可能一下子就到瓶頸值了港准。
為了解決這個(gè)過慢或過快的問題，我們可以把第一種方法和第二種方法結(jié)合起來咧欣。也就是說浅缸，我們剛開始可以以指數(shù)的速度增長，增長到某一個(gè)值魄咕，我們把這個(gè)值稱之為閾值吧衩椒，用變量 ssthresh 代替。當(dāng)增長到閾值時(shí)哮兰，我們就不在以指數(shù)增長了毛萌，而是一個(gè)一個(gè)線性增長。
所以最終的策略是：前期指數(shù)增長喝滞，到達(dá)閾值之后阁将，就以一個(gè)一個(gè)線性的速度來增長。
(注：8之后其實(shí)是直線的右遭，那里只是彎曲了一下)
我們也把指數(shù)增長階段稱之為慢啟動做盅，線性增長階段稱之為擁塞避免
三、到了瓶頸值之后怎么辦窘哈？
無論是指數(shù)增長還是一個(gè)一個(gè)增長吹榴，最終肯定會出現(xiàn)超時(shí)事件，總不可能無限增長吧滚婉。當(dāng)出現(xiàn)超時(shí)事件時(shí)图筹，我們就認(rèn)為此時(shí)網(wǎng)絡(luò)出現(xiàn)了擁塞了，不能再繼續(xù)增長了满哪。我們就把這個(gè)時(shí)候的N的值稱之為瓶頸值吧婿斥，用MAX 這個(gè)字母來代替吧，即最大值哨鸭。
注：這里再次提醒閾值過后是一個(gè)一個(gè)線性增長民宿，圖中之所以彎曲是因?yàn)槲耶媹D原因?qū)е碌?/p>
當(dāng)達(dá)到最大值MAX之后，我們該怎么辦呢像鸡？
當(dāng)?shù)竭_(dá)最大值之后我們采取的策略是這樣的：
我們就回到最初的最初的狀態(tài)活鹰，也就是說從1哈恰，2，4志群，8.....開始,不過這個(gè)時(shí)候我們還會把ssthresh調(diào)小着绷，調(diào)為MAX值的一半，即ssthresh = MAX / 2锌云。
圖中閾值為8荠医，瓶頸值是14；超時(shí)事件發(fā)生后桑涎，閾值為14 / 2 = 7彬向。
四、超時(shí)事件就一定是網(wǎng)絡(luò)擁塞攻冷？
超時(shí)事件發(fā)送就一定是網(wǎng)絡(luò)出現(xiàn)了擁堵嗎娃胆？其實(shí)也有可能不是出現(xiàn)了網(wǎng)絡(luò)擁堵，有可能是因?yàn)槟硞€(gè)數(shù)據(jù)包出現(xiàn)了丟失或者損害了等曼，導(dǎo)致了這個(gè)數(shù)據(jù)包超時(shí)事件發(fā)生了
為了防止這種情況里烦，我們是通過冗余 ACK來處理的。我們都知道禁谦，數(shù)據(jù)包是有序號的胁黑，如果A給B發(fā)送M1, M2, M3, M4, M5...N個(gè)數(shù)據(jù)包，如果B收到了M1, M2, M4....卻始終沒有收到M3枷畏，這個(gè)時(shí)候就會重復(fù)確認(rèn)M2别厘，意在告訴A,M3還沒收到，可能是丟失
當(dāng)A連續(xù)收到了三個(gè)確認(rèn)M2的ACK拥诡，且M3超時(shí)事件還沒發(fā)生触趴。A就知道M3可能丟失了，這個(gè)時(shí)候A就不必等待M3設(shè)置的計(jì)時(shí)器到期了渴肉，而是快速重傳M3冗懦。并且把ssthresh設(shè)置為MAX的一半，即ssthresh = MAX/2仇祭，但是這個(gè)時(shí)候并非把控制窗口N設(shè)置為1披蕉，而是讓N = ssthresh，N在一個(gè)一個(gè)增長乌奇。
我們也把這種情況稱之為快速恢復(fù)没讲。而這種具有快速恢復(fù)的TCP版本稱之為TCP Reno。
還有另外一種TCP版本礁苗，無論是收到三個(gè)相同的ACK還是發(fā)生超時(shí)事件爬凑，都把擁塞窗口的大小設(shè)為1，從最初狀態(tài)開始试伙，這種版本的TCP我們稱之為TCP Tahoe嘁信。
5.3 擁塞避免
讓擁塞窗口cwnd緩慢地增大于样，每經(jīng)過一個(gè)往返時(shí)間RTT就把發(fā)送方的擁塞窗口cwnd加1，而不是加倍潘靖。這樣擁塞窗口cwnd按線性規(guī)律緩慢增長穿剖。
無論在慢開始階段還是在擁塞避免階段，只要發(fā)送方判斷網(wǎng)絡(luò)出現(xiàn)擁塞（其根據(jù)就是沒有收到確認(rèn)）卦溢，就要把慢開始門限ssthresh設(shè)置為出現(xiàn)擁塞時(shí)的發(fā)送 方窗口值的一半（但不能小于2）糊余。然后把擁塞窗口cwnd重新設(shè)置為1，執(zhí)行慢開始算法既绕。這樣做的目的就是要迅速減少主機(jī)發(fā)送到網(wǎng)絡(luò)中的分組數(shù)啄刹，使得發(fā)生 擁塞的路由器有足夠時(shí)間把隊(duì)列中積壓的分組處理完畢。
5.4 快重傳
有時(shí)個(gè)別報(bào)文段會在網(wǎng)絡(luò)中丟失凄贩，但實(shí)際上網(wǎng)絡(luò)并未發(fā)生擁塞。如果發(fā)送方遲遲收不到確認(rèn)袱讹，就會產(chǎn)生超時(shí)疲扎，就會誤認(rèn)為網(wǎng)絡(luò)發(fā)生了擁塞。這就導(dǎo)致發(fā)送方錯(cuò)誤地啟動慢開始捷雕，把擁塞窗口cwnd又設(shè)置為1椒丧，因而降低了傳輸效率。
快重傳算法可以避免這個(gè)問題救巷『快重傳算法首先要求接收方每收到一個(gè)失序的報(bào)文段后就立即發(fā)出重復(fù)確認(rèn)，使發(fā)送方及早知道有報(bào)文段沒有到達(dá)對方浦译。
發(fā)送方只要一連收到三個(gè)重復(fù)確認(rèn)就應(yīng)當(dāng)立即重傳對方尚未收到的報(bào)文段棒假，而不必繼續(xù)等待重傳計(jì)時(shí)器到期。由于發(fā)送方盡早重傳未被確認(rèn)的報(bào)文段精盅，因此采用快重傳后可以使整個(gè)網(wǎng)絡(luò)吞吐量提高約20%帽哑。
5.5 快恢復(fù)
當(dāng)發(fā)送方連續(xù)收到三個(gè)重復(fù)確認(rèn)，就會把慢開始門限ssthresh減半叹俏，接著把cwnd值設(shè)置為慢開始門限ssthresh減半后的數(shù)值妻枕，然后開始執(zhí)行擁塞避免算法，使擁塞窗口緩慢地線性增大粘驰。
在采用快恢復(fù)算法時(shí)屡谐，慢開始算法只是在TCP連接建立時(shí)和網(wǎng)絡(luò)出現(xiàn)超時(shí)時(shí)才使用。 采用這樣的擁塞控制方法使得TCP的性能有明顯的改進(jìn)蝌数。
關(guān)注我愕掏，加我好友拉你進(jìn)面試群，一起討論面試干貨 / 套路籽前，大家一起升職加薪
讓我?guī)湍阋?guī)劃下學(xué)習(xí)線路 & 職業(yè)規(guī)劃線路亭珍，幫你升職加薪敷钾。
關(guān)注公眾號：「測試猿溫大大」
