聲明：本文內(nèi)容純屬博主自己查找和歸納的個人所需的知識點飒硅，僅作參考柄驻，如有錯誤狐树，博主強烈希望您指出。如果您是某個知識點的原創(chuàng)博主鸿脓，如有需要抑钟，可聯(lián)系本人加上鏈接。本文內(nèi)容會根據(jù)博主所需進行更新野哭，希望大家多多關照在塔。
由于博主不是計算機專業(yè)出身，個人能力有限拨黔，本文內(nèi)容涉及到博主的知識盲區(qū)蛔溃，在這領域不知道需要掌握多少，只是把自己看到的大概歸納一下，請見諒城榛。也希望網(wǎng)友們可以指點指點揪利，謝謝！
網(wǎng)絡層次劃分
TCP/IP 4層模型：應用層狠持、傳輸層疟位、網(wǎng)絡層、網(wǎng)絡接口層
TCP/IP 5層模型：應用層喘垂、傳輸層甜刻、網(wǎng)絡層、數(shù)據(jù)鏈路層正勒、物理層
OSI 7層模型：應用層得院、表示層、會話層章贞、傳輸層祥绞、網(wǎng)絡層、數(shù)據(jù)鏈路層鸭限、物理層
物理層：發(fā)送高低電壓即電信號
數(shù)據(jù)鏈路層：電信號分組蜕径，以太網(wǎng)協(xié)議，單位為幀
網(wǎng)絡層：對子網(wǎng)間的數(shù)據(jù)包進行路由選擇败京，IP協(xié)議兜喻，單位為IP數(shù)據(jù)報
傳輸層：負責端到端的可靠數(shù)據(jù)傳輸，網(wǎng)關赡麦，TCP協(xié)議和UDP協(xié)議
會話層：進程間的會話
表示層：數(shù)據(jù)的加密朴皆、壓縮、格式轉(zhuǎn)換等
應用層：應用程序
以太網(wǎng)數(shù)據(jù)包
???????以太網(wǎng)數(shù)據(jù)包的頭為14字節(jié)泛粹，包括源地址遂铡、目標地址、數(shù)據(jù)類型晶姊，尾4字節(jié)忧便。
???????數(shù)據(jù)部分最短46字節(jié)，最長1500字節(jié)帽借，這個大小稱為MTU（最長傳輸單元），內(nèi)容為IP數(shù)據(jù)報超歌，報頭占20字節(jié)砍艾。因此以太網(wǎng)包最短64字節(jié)，最長1518字節(jié)
???????數(shù)據(jù)部分超過MTU就分片發(fā)送巍举，分片需包含IP頭和TCP/UDP頭
???????以TCP為例脆荷，以太網(wǎng)數(shù)據(jù)包數(shù)據(jù)部分有2000字節(jié)，包含IP頭20字節(jié)，TCP頭20字節(jié)（UDP8字節(jié)）蜓谋，以及應用數(shù)據(jù)1960字節(jié)梦皮，需要做分片操作，第一部分1500字節(jié)桃焕，包含IP頭20字節(jié)剑肯，TCP頭20字節(jié)，應用數(shù)據(jù)1460字節(jié)（這個值稱為最大報文段長度MSS）观堂，第二部分540字節(jié)让网，包含IP頭20字節(jié)，TCP頭20字節(jié)师痕，應用數(shù)據(jù)500字節(jié)
???????另外溃睹，1492的MTU值的來源，是因為PPPoE協(xié)議胰坟。PPP協(xié)議是寬帶運營商用于對用戶認證計費的（TCP/IP以太網(wǎng)無此功能）因篇。PPPoE頭尾一共8字節(jié)，所以有效載荷MTU變小了笔横，原來有1500字節(jié)竞滓，現(xiàn)在只剩1492
TCP協(xié)議和UDP協(xié)議
???????TCP傳輸控制協(xié)議協(xié)議是是一種面向連接的、可靠的狠裹、基于字節(jié)流的傳輸層通信協(xié)議虽界。
???????TCP/IP協(xié)議是Internet最基本的協(xié)議、Internet國際互聯(lián)網(wǎng)絡的基礎涛菠，由網(wǎng)絡層的IP協(xié)議和傳輸層的TCP協(xié)議組成莉御。通俗而言：TCP負責發(fā)現(xiàn)傳輸?shù)膯栴}，一有問題就發(fā)出信號俗冻，要求重新傳輸礁叔，直到所有數(shù)據(jù)安全正確地傳輸?shù)侥康牡亍６鳬P是給因特網(wǎng)的每一臺聯(lián)網(wǎng)設備規(guī)定一個地址迄薄。
???????UDP用戶數(shù)據(jù)報協(xié)議琅关，是面向無連接的通訊協(xié)議，由于通訊不需要連接讥蔽，所以可以實現(xiàn)廣播發(fā)送涣易。UDP通訊時不需要接收方確認，屬于不可靠的傳輸冶伞，可能會出現(xiàn)丟包現(xiàn)象新症，實際應用中要求程序員編程驗證（例如模擬TCP的連接和斷開，要保證數(shù)據(jù)的有效性响禽、有序性）徒爹。
???????TCP 與 UDP 的區(qū)別：TCP是面向連接的荚醒，可靠的字節(jié)流服務；UDP是面向無連接的隆嗅，不可靠的數(shù)據(jù)報服務界阁。
三次握手和四次揮手
三次握手：
- 客戶端發(fā)送SYN報文給服務端，進入SYN-SEND狀態(tài)胖喳；
- 服務端收到SYN報文后發(fā)送SYN+ACK報文給客戶端泡躯，進入SYN-RCVD狀態(tài)；
- 客戶端收到SYN+ACK報文后發(fā)送ACK報文給服務端禀晓，雙方進入ESTABLISED狀態(tài)
四次揮手：
- 客戶端發(fā)送FIN報文給服務端精续，進入FIN_WAIT-1狀態(tài)；
- 服務端收到FIN報文粹懒，發(fā)送ACK報文重付，繼續(xù)回復完客戶端前面的事務，進入CLOSE-WAIT凫乖，客戶端收到ACK報文后進入FIN-WAIT-2狀態(tài)确垫，接收服務端剩下的回復；
- 服務端也發(fā)送FIN報文給客戶端帽芽，進入LAST-ACK狀態(tài)删掀；
- 客戶端收到FIN報文后發(fā)送ACK報文給服務端，進入TIME-WAIT狀態(tài)导街，如果服務端沒有收到ACK報文則可以重傳FIN報文披泪，服務端收到ACK報文后關閉服務
為什么3次握手
???????假設改為兩次握手，client端發(fā)送的一個連接請求在服務器滯留了搬瑰，由于連接超時client端會放棄款票，這個連接請求是無效的，但等到服務器收到這個無效的請求泽论，服務器還是會繼續(xù)認為client想要建立一個新的連接艾少，于是就建立連接了，服務器此時會一直等client端發(fā)數(shù)據(jù)翼悴，這樣就浪費掉很多server端的資源
為什么4次揮手
???????如果客戶端在收到服務器給它的斷開連接的請求之后缚够，回應完服務器就直接斷開連接的話，如果因為一些原因鹦赎，服務器沒有收到回應谍椅，會以為客戶端還沒關閉，這樣服務器就會一直開著古话。所以客戶端要等待兩個最長報文段壽命的時間毯辅，以便于服務器沒有收到請求之后重新發(fā)送請求。
???????在釋放連接的過程中會有一些無效的滯留報文煞额，這些報文在經(jīng)過2MSL的時間內(nèi)就可以發(fā)送到目的地，不會滯留在網(wǎng)絡中。這樣就可以避免在下一個連接中出現(xiàn)上一個連接的滯留報文了
Socket通信流程
- 服務端這邊首先創(chuàng)建一個Socket（Socket()）膊毁，然后綁定IP地址和端口號（Bind()）胀莹，之后注冊監(jiān)聽（Listen()），這樣服務端就可以監(jiān)聽指定的Socket地址了婚温；
- 客戶端這邊也創(chuàng)建一個Socket（Socket()）并打開描焰，然后根據(jù)服務器IP地址和端口號向服務器Socket發(fā)送連接請求（Connect()）；
- 服務器Socket監(jiān)聽到客戶端Socket發(fā)來的連接請求之后栅螟，被動打開荆秦，并調(diào)用Accept()函數(shù)接收請求，這樣客戶端和服務器之間的連接就建立好了力图；
- 成功建立連接之后客戶端和服務器就可以進行數(shù)據(jù)交互（Receive()步绸、Send()）；
- 交互完之后吃媒，各自關閉連接（Close()）瓤介，交互結(jié)束。
擁塞控制
???????參考：TCP慢啟動赘那、擁塞避免刑桑、快速重傳、快速恢復
???????背景：為了防止網(wǎng)絡的擁塞現(xiàn)象募舟，TCP提出了一系列的擁塞控制機制祠斧。最初由V. Jacobson在1988年的論文中提出的TCP的擁塞控制由“慢啟動(Slow start)”和“擁塞避免(Congestion avoidance)”組成，后來TCP Reno版本中又針對性的加入了“快速重傳(Fast retransmit)”拱礁、“快速恢復(Fast Recovery)”算法琢锋，再后來在TCP NewReno中又對“快速恢復”算法進行了改進，近些年又出現(xiàn)了選擇性應答( selective acknowledgement,SACK)算法觅彰，還有其他方面的大大小小的改進吩蔑，成為網(wǎng)絡研究的一個熱點
???????TCP的擁塞控制主要原理依賴于一個擁塞窗口(cwnd)來控制，還有一個對端的接收窗口(rwnd)用于流量控制填抬。因此TCP的真正的發(fā)送窗口=min(rwnd, cwnd)烛芬。但是rwnd是由對端確定的，網(wǎng)絡環(huán)境對其沒有影響飒责，所以在考慮擁塞的時候我們一般不考慮rwnd的值赘娄，我們暫時只討論如何確定cwnd值的大小。
???????關于cwnd的單位宏蛉，在TCP中是以字節(jié)來做單位的遣臼，假設TCP每次傳輸都按照MSS大小來發(fā)送數(shù)據(jù)，則可以認為cwnd按照數(shù)據(jù)包個數(shù)來做單位拾并，所以有時我們說cwnd增加1也就是相當于字節(jié)數(shù)增加1個MSS大小揍堰。
慢啟動
???????當新建連接時鹏浅，cwnd初始化為1個最大報文段(MSS)大小，發(fā)送端開始按照擁塞窗口大小發(fā)送數(shù)據(jù)屏歹，每當有一個報文段被確認隐砸，cwnd就增加1個MSS大小。這樣cwnd的值就隨著網(wǎng)絡往返時間(RTT)呈指數(shù)級增長蝙眶，事實上季希，慢啟動的速度一點也不慢，只是它的起點比較低一點而已幽纷。我們可以簡單計算下：
???????開始 ---> cwnd = 1
???????經(jīng)過1個RTT后 ---> cwnd = 2 * 1 = 2
???????經(jīng)過2個RTT后 ---> cwnd = 2 * 2 = 4
???????經(jīng)過3個RTT后 ---> cwnd = 4 * 2 = 8
???????如果帶寬為W式塌，那么經(jīng)過RTT*log2W時間就可以占滿帶寬
擁塞避免
???????從慢啟動可以看到，cwnd可以很快的增長上來友浸，從而最大程度利用網(wǎng)絡帶寬資源峰尝，但是cwnd不能一直這樣無限增長下去，一定需要某個限制尾菇。TCP使用了一個叫慢啟動門限(ssthresh)的變量境析，當cwnd超過該值后，慢啟動過程結(jié)束派诬，進入擁塞避免階段劳淆。對于大多數(shù)TCP實現(xiàn)來說，ssthresh的值是65536(同樣以字節(jié)計算)默赂。擁塞避免的主要思想是加法增大沛鸵，也就是cwnd的值不再指數(shù)級往上升，開始加法增加缆八。此時當窗口中所有的報文段都被確認時曲掰，cwnd的大小加1，cwnd的值就隨著RTT開始線性增加奈辰，這樣就可以避免增長過快導致網(wǎng)絡擁塞栏妖，慢慢的增加調(diào)整到網(wǎng)絡的最佳值。
???????擁塞現(xiàn)象的判定：TCP對每一個報文段都有一個定時器奖恰，稱為重傳定時器(RTO)吊趾，當RTO超時且還沒有得到數(shù)據(jù)確認，那么TCP就會對該報文段進行重傳瑟啃。當發(fā)生超時時论泛，出現(xiàn)擁塞的可能性就很大，某個報文段可能在網(wǎng)絡中某處丟失蛹屿，并且后續(xù)的報文段也沒有了消息屁奏，在這種情況下，TCP反應比較“強烈”：
???????1.把ssthresh降低為cwnd值的一半
???????2.把cwnd重新設置為1
???????3.重新進入慢啟動過程
???????從整體上來講错负，TCP擁塞控制窗口變化的原則是AIMD原則坟瓢，即加法增大勇边、乘法減小
快速重傳
???????其實TCP還有一種情況會進行重傳：那就是收到3個相同的ACK。TCP在收到亂序到達包時就會立即發(fā)送ACK，TCP利用3個相同的ACK來判定數(shù)據(jù)包的丟失，此時進行快速重傳朝抖，快速重傳做的事情有：
???????1.把ssthresh設置為cwnd的一半
???????2.把cwnd再設置為ssthresh的值(具體實現(xiàn)有些為ssthresh+3)
???????3.重新進入擁塞避免階段
快速恢復
???????后來的“快速恢復”算法是在上述的“快速重傳”算法后添加的邢锯，當收到3個重復ACK時，TCP最后進入的不是擁塞避免階段谊囚，而是快速恢復階段怕享。快速重傳和快速恢復算法一般同時使用镰踏。
???????快速恢復的思想是“數(shù)據(jù)包守恒”原則函筋，即同一個時刻在網(wǎng)絡中的數(shù)據(jù)包數(shù)量是恒定的，只有當“老”數(shù)據(jù)包離開了網(wǎng)絡后奠伪，才能向網(wǎng)絡中發(fā)送一個“新”的數(shù)據(jù)包跌帐，如果發(fā)送方收到一個重復的ACK，那么根據(jù)TCP的ACK機制就表明有一個數(shù)據(jù)包離開了網(wǎng)絡绊率，于是cwnd加1谨敛。如果能夠嚴格按照該原則那么網(wǎng)絡中很少會發(fā)生擁塞，事實上擁塞控制的目的也就在修正違反該原則的地方滤否。
???????具體來說快速恢復的主要步驟是：
???????1.當收到3個重復ACK時脸狸，把ssthresh設置為cwnd的一半，把cwnd設置為ssthresh的值加3藐俺，然后重傳丟失的報文段炊甲。（加3的原因是因為收到3個重復的ACK，表明有3個“老”的數(shù)據(jù)包離開了網(wǎng)絡）
???????2.如果再收到同樣的重復的ACK欲芹，擁塞窗口就再增加1卿啡，但ssthresh的值不變，如果是新的重復的ACK菱父，則到達3個又重復第一步的動作颈娜。
???????3.當收到新的數(shù)據(jù)包的ACK時，把cwnd設置為第一步中的ssthresh的值滞伟。（原因是因為該ACK確認了新的數(shù)據(jù)揭鳞，說明從重復ACK時的數(shù)據(jù)都已收到，該恢復過程已經(jīng)結(jié)束梆奈，可以回到恢復之前的狀態(tài)了野崇，也即再次進入擁塞避免狀態(tài)）
???????然而在實際中，一個重傳超時可能導致許多的數(shù)據(jù)包的重傳亩钟，當多個數(shù)據(jù)包從一個數(shù)據(jù)窗口中丟失時并且觸發(fā)快速重傳和快速恢復算法時乓梨，問題就產(chǎn)生了鳖轰。
???????因此NewReno出現(xiàn)了，它在Reno快速恢復的基礎上稍加了修改扶镀，可以恢復一個窗口內(nèi)多個包丟失的情況蕴侣。具體來講就是：Reno在收到一個新的數(shù)據(jù)的ACK時就退出了快速恢復狀態(tài)了，而NewReno需要收到該窗口內(nèi)所有數(shù)據(jù)包的確認后才會退出快速恢復狀態(tài)臭觉，從而更一步提高吞吐量
選擇性應答(SACK)算法
???????SACK就是改變TCP的確認機制昆雀，最初的TCP只確認當前已連續(xù)收到的數(shù)據(jù)，SACK則把亂序等信息會全部告訴對方蝠筑，從而減少數(shù)據(jù)發(fā)送方重傳的盲目性狞膘。
???????例如，序號1什乙，2挽封，3，5臣镣，7的數(shù)據(jù)收到了辅愿，普通的ACK只會確認序列號4，而SACK會把當前的5忆某，7已經(jīng)收到的信息在SACK選項里面告知對端点待，對端就能直接重發(fā)序號4和6的數(shù)據(jù)，不用再在序號6的數(shù)據(jù)上花時間褒繁，從而提高性能亦鳞。
???????當使用SACK的時候，NewReno算法可以不使用棒坏，因為SACK本身攜帶的信息就可以使得發(fā)送方有足夠的信息來知道需要重傳哪些包燕差，而不需要重傳哪些包。
HTTP(可選)
???????超文本傳輸協(xié)議HTTP是互聯(lián)網(wǎng)上應用最為廣泛的一種網(wǎng)絡協(xié)議坝冕。所有的WWW文件都必須遵守這個標準徒探。
請求包
???????當瀏覽器向Web服務器發(fā)出請求時，它向服務器傳遞了一個數(shù)據(jù)塊喂窟，也就是請求信息测暗，HTTP請求信息由3部分組成：
l 請求方法URI協(xié)議/版本
l 請求頭(Request Header)
l 請求正文
???????下面是一個HTTP請求的例子：
GET/sample.jspHTTP/1.1
Accept:image/gif.image/jpeg,/
Accept-Language:zh-cn
Connection:Keep-Alive
Host:localhost
User-Agent:Mozila/4.0(compatible;MSIE5.01;Window NT5.0)
Accept-Encoding:gzip,deflate
username=jinqiao&password=1234
HTTP 協(xié)議包括的請求：
- GET：請求讀取由URL所標志的信息。
- POST：給服務器添加信息（如注釋）磨澡。
（Get是從服務器上獲取數(shù)據(jù)碗啄，Post是向服務器傳送數(shù)據(jù)） - PUT：在給定的URL下存儲一個文檔。
- DELETE：刪除給定的URL所標志的資源稳摄。
- HEAD：類似于 GET 請求稚字，只不過返回的響應中沒有具體的內(nèi)容，用于獲取報頭
- CONNECT：HTTP/1.1 協(xié)議中預留給能夠?qū)⑦B接改為管道方式的代理服務器
- OPTIONS：允許客戶端查看服務器的性能。
- TRACE：回顯服務器收到的請求胆描，主要用于測試或診斷瘫想。
- PATCH：是對 PUT 方法的補充，用來對已知資源進行局部更新 昌讲。
???????請求頭和響應頭的信息參考：HTTP 請求包和響應包 （網(wǎng)絡篇）
響應包
???????HTTP響應也由3個部分構(gòu)成国夜，分別是：
l 協(xié)議狀態(tài)版本代碼描述
l 響應頭(Response Header)
l 響應正文
???????下面是一個HTTP響應的例子：
HTTP/1.1 200 OK
Server:Apache Tomcat/5.0.12
Date:Mon,6Oct2003 13:23:42 GMT
Content-Length:112
<html>
<head>
<title>HTTP響應示例<title>
</head>
<body>
Hello HTTP!
</body>
</html>
HTTP答應碼：
- 1XX－信息類(Information),表示收到Web瀏覽器請求，正在進一步的處理中
- 2XX－成功類（Successful）,表示用戶請求被正確接收短绸，理解和處理例如：200 OK
- 3XX-重定向類(Redirection),表示請求沒有成功车吹，客戶必須采取進一步的動作。
- 4XX-客戶端錯誤(Client Error)醋闭，表示客戶端提交的請求有錯誤 例如：404 NOT Found礼搁，意味著請求中所引用的文檔不存在。
- 5XX-服務器錯誤(Server Error)表示服務器不能完成對請求的處理：如 500
其他
???????想實現(xiàn)網(wǎng)絡通信目尖，每臺主機需具備四要素：本機的IP地址、子網(wǎng)掩碼扎运、網(wǎng)關的IP地址瑟曲、DNS的IP地址
獲取這四要素分兩種方式：
???????1.靜態(tài)獲取 即手動配置
???????2.動態(tài)獲取 通過dhcp獲取
???????DHCP（動態(tài)主機配置協(xié)議）是一個局域網(wǎng)的網(wǎng)絡協(xié)議。指的是由服務器控制一段lP地址范圍豪治，客戶機登錄服務器時就可以自動獲得服務器分配的lP地址和子網(wǎng)掩碼洞拨。
