網絡協議層

tcp udp區別

	tcp	udp
有無鏈接	有鏈接	無鏈接
可靠性	可靠，確認重傳機制	不可靠
速度	慢	快
順序	保證順序，滑動窗口	無順序
單播/多播	點到點	一對一，一對多
面向字節流/報文	面向字節流	面向報文
報文頭長度	長20字節	短8字節
擁塞控制	有擁塞控制，防止網絡過載	沒有擁塞控制
應用領域	時間要求不高，可靠性要求高，金融等	遊戲視頻等
應用層協議	http、https、ftp等	dhcp、dns協議等

如何理解udp面向報文：發送方的udp對應用程序交下來的報文再添加首部後就向下交付，udp對應用層交付下來的報文既不合並也不拆分，也就是說有多長，UDP就照樣發送，即一次發送一個報文，因此是面向報文的
如何理解TCP是面向字節流的：TCP不保證接收方收到的數據塊和發送方所發出的的數據塊相等，可是保證發送和接收的字節流徹底同樣，因此是面向字節流的

tcp創建鏈接三次握手，斷開四次

tcp標誌位
SYN(synchronous創建聯機)
ACK(acknowledgement 確認)
PSH(push傳送)
FIN(finish結束)
RST(reset重置)
URG(urgent緊急)
Sequence number(順序號碼)
Acknowledge number(確認號碼)

三次握手過程

第一次握手：Client將標誌位SYN置爲1，隨機產生一個值seq=J，並將該數據包發送給Server，Client進入SYN_SENT狀態，等待Server確認。

SYN：同步序列編號(Synchronize Sequence Numbers)

第二次握手：Server收到數據包後由標誌位SYN=1知道Client請求創建鏈接，Server將標誌位SYN和ACK都置爲1，ack=J+1，隨機產生一個值seq=K，並將該數據包發送給Client以確認鏈接請求，Server進入SYN_RCVD狀態。

第三次握手：Client收到確認後，檢查ack是否爲J+1，ACK是否爲1，若是正確則將標誌位ACK置爲1，ack=K+1，並將該數據包發送給Server，Server檢查ack是否爲K+1，ACK是否爲1，若是正確則鏈接創建成功，Client和Server進入ESTABLISHED狀態，完成三次握手，隨後Client與Server之間能夠開始傳輸數據了

爲何要三次握手？

謝希仁版《計算機網絡》中的例子是這樣的，「已失效的鏈接請求報文段」的產生在這樣一種狀況下：client發出的第一個鏈接請求報文段並無丟失，而是在某個網絡結點長時間的滯留了，以至延誤到鏈接釋放之後的某個時間纔到達server。原本這是一個早已失效的報文段。但server收到此失效的鏈接請求報文段後，就誤認爲是client再次發出的一個新的鏈接請求。因而就向client發出確認報文段，贊成創建鏈接。假設不採用「三次握手」，那麼只要server發出確認，新的鏈接就創建了。因爲如今client並無發出創建鏈接的請求，所以不會理睬server的確認，也不會向server發送ack包。server卻覺得新的運輸鏈接已經創建，並一直等待client發來數據。這樣，server的不少資源就白白浪費掉了。採用「三次握手」的辦法能夠防止上述現象發生。例如剛纔那種狀況，client不會向server的確認發出確認。server因爲收不到確認，就知道client並無要求創建鏈接。在謝希仁著《計算機網絡》第四版中講「三次握手」的目的是「爲了防止已失效的鏈接請求報文段忽然又傳送到了服務端，於是產生錯誤」

四次握手斷開鏈接

1.第一次揮手：Client發送一個FIN，用來關閉Client到Server的數據傳送，Client進入FIN_WAIT_1狀態。

2.第二次揮手：Server收到FIN後，發送一個ACK給Client，確認序號爲收到序號+1（與SYN相同，一個FIN佔用一個序號），Server進入CLOSE_WAIT狀態。

3.第三次揮手：Server發送一個FIN，用來關閉Server到Client的數據傳送，Server進入LAST_ACK狀態。

4.第四次揮手：Client收到FIN後，Client發送一個ACK給Server，接着進入TIME_WAIT狀態，確認序號爲收到序號+1， Server進入CLOSED狀態，完成四次揮手。

time_wait狀態主要作了什麼

1.假設客戶端主動斷開鏈接，向服務器發送fin報文，這個報文主要告訴服務器客戶端已經沒有數據想要傳給服務器，可是服務器你若是有數據沒傳輸完的話，先不用斷開socket鏈接，能夠繼續發你的數據，先給客戶端發ack報文。2.服務器收到報文，看了fin的報文，給客戶端發了ack報文，告訴客戶端服務器已經收到了消息，但我還有事沒作完，讓客戶端等會。3.這時候客戶端進入FIN_WAIT狀態，即等待服務器給他發fin報文。當服務器肯定傳輸的數據都發完了，再向客戶端發送fin報文。告訴客戶端我已經傳輸完全部數據了，能夠關閉socket鏈接。4.客戶端收到fin報文，就知道socket要斷開鏈接了，向服務器發送ack報文，但客戶端不肯定這個報文是否傳到服務器了，因而進入Time_wait狀態，若是服務器沒有收到ack報文則會進行fin報文重傳，若是客戶端等待30s沒有收到消息說明鏈接服務器端已經關閉了，客戶端能夠安心關閉了。這樣tcp就斷開了。 在TIME_WAIT狀態中，若是TCP client端最後一次發送的ACK丟失了，它將從新發送。TIME_WAIT狀態中所須要的時間是依賴於實現方法的。典型的值爲30秒、1分鐘和2分鐘。等待以後鏈接正式關閉，而且全部的資源(包括端口號)都被釋放。 若是Client直接CLOSED了，那麼因爲IP協議的不可靠性或者是其它網絡緣由，致使Server沒有收到Client最後回覆的ACK。那麼Server就會在超時以後繼續發送FIN，此時因爲Client已經CLOSED了，就找不到與重發的FIN對應的鏈接，最後Server就會收到RST而不是ACK，Server就會覺得是鏈接錯誤把問題報告給高層。這樣的狀況雖然不會形成數據丟失，可是卻致使TCP協議不符合可靠鏈接的要求。因此，Client不是直接進入CLOSED，而是要保持TIME_WAIT，當再次收到FIN的時候，可以保證對方收到ACK，最後正確的關閉鏈接

爲何鏈接的時候是三次握手，關閉的時候倒是四次握手？

答：由於當Server端收到Client端的SYN鏈接請求報文後，能夠直接發送SYN+ACK報文。其中ACK報文是用來應答的，SYN報文是用來同步創建聯機的（確認和創建聯機能夠一塊兒發）。可是關閉鏈接時，當Server端收到FIN報文時，極可能並不會當即關閉SOCKET，因此只能先回復一個ACK報文，告訴Client端，"你發的FIN報文我收到了"。只有等到我Server端全部的報文都發送完了，我才能發送FIN報文，所以不能一塊兒發送。故須要四步握手

osi7層協議、5層協議、4層協議

講解計算機網絡的很好的視頻： www.warriorsofthe.net/movie.html

mac地址（硬件地址）和ip地址（軟件地址）聯繫和區別？

IP地址是放在IP數據報的首部，硬件地址放在MAC幀的首部。在網絡層及網絡層以上使用
的是IP地址，數據鏈路層及如下使用的是硬件地址，當IP數據報放入數據鏈路層的MAC幀
中之後，整個IP數據報就成爲MAC幀的數據，於是在數據鏈路層是看不見IP地址的。
另外IP數據報向下傳輸時，經過ARP協議找到IP地址對應的硬件地址，封裝在MAC幀首部
複製代碼

	IP地址	MAC地址
可見協議層	網絡層及以上	數據鏈路層及如下
傳輸是否可變	整個傳輸過程當中，源IP，目的IP始終不變	傳輸過程源MAC地址，目的MAC地址根據當前傳輸主機或路由器的MAC地址變化

數據傳輸過程詳解

IP地址有網絡號和主機號組成，網絡號相同的全部主機能夠成爲屬於同一個網絡，不一樣網絡的主機經過路由器鏈接，因此路由器有兩個IP地址 如今A中一個應用向B中一個應用傳輸數據，A中有5層協議，應用層封裝數據給傳輸層，傳輸層會把端口信息封裝在數據中往下傳，到網絡層把源IP，目的IP封裝進去，再往下數據鏈路層會將IP對應的Mac地址放在Mac幀首部，Mac幀裏有源Mac地址和目的Mac地址，目的Mac地址就是當前要去的主機或者路由器，根據這個地址就開始在網絡鏈路上傳輸了，中間通過路由器，路由器從下網上把數據剝開到網絡層查看目的IP，判斷下一跳該是哪個主機，而後找到對應Mac地址，在往下封裝數據，就這樣一直傳輸，直到最後目的主機，從下往上剝開數據直到應用層，這樣數據就傳輸過去了

散知識點

網絡層不提供可靠傳輸，運輸層能夠提供可靠傳輸        
路由器僅根據目的主機的**網絡號**轉發分組（而不考慮目的主機號），路由表裏面是[
目的網絡 下一跳地址]，這樣路由表裏面的項目數就大量減小，節省存儲空間和查找時間   
當一個主機同時鏈接在兩個網絡上，該主機就必須有兩個相應的IP地址，網絡號必須是不
同的      
具備不一樣網絡號的局域網必須使用路由器互連        
同一個局域網上的主機或路由器的IP地址中的網絡號必須是同樣的      
網絡層使用的是IP地址，但實際網絡的鏈路上傳送數據幀時，仍是要使用該網絡的硬件地址
網絡鏈路上傳送的幀是按照硬件地址找到目的主機的，爲何還須要使用抽象的IP地址，
不直接使用硬件地址呢？（世界上有各類各樣的網絡，使用不一樣的硬件地址，若是隻使用
硬件地址，要進行很是複雜的硬件地址轉換工做，但IP編址把這個問題解決了，連接到互
聯網上的主機只須要有一個惟一的IP地址，他們之間的通訊就像是在同一個網絡上同樣方
便，能夠想象每次判斷目的IP地址而後直到下一步哪裏傳，若是隻是硬件地址，怎麼知道
下一步該給誰，難道所有都廣播問誰是這個硬件地址嗎？）

當網絡邊緣部分中的兩臺主機使用網絡核心部分的功能進行端到端通訊時，只有主機的協
議棧有**運輸層**，而網絡核心部分中的路由器在轉發分組時只用到**下三層**的功能，
以下圖所示
複製代碼

ARP地址解析協議

每一臺主機都設有一個ARP高速緩存（ARPcache），裏面有本局域網上的各主機和路由器的
IP地址到硬件地址的映射表，有一些本局域網主機信息沒有出如今映射表中，該主機會發
一個**廣播**，廣播內容是「個人IP地址是***，MAC地址是****，我想知道IP地址是***的
主機的MAC地址」，無關主機收到廣播會丟棄，相關主機收到會把發送廣播主機的信息存儲
到本身的ARP映射表裏，而後發送**單播**消息到查詢主機
複製代碼

須要注意的是，ARP是解決同一個局域網上的主機或者路由器的IP地址和硬件地址的映射問題，當源主機須要將IP數據報往數據鏈路層傳輸，判斷屬於同一網絡，纔會使用ARP查詢他的硬件地址，若是不是同一個網絡會查詢路由器的硬件地址，將數據傳給路由器，路由器拿到數據判斷數據下一步怎麼傳
圖上說明的是ARP使用的四中典型狀況

流量控制和擁塞控制

	流量控制	擁塞控制
含義	抑制發送端發送數據的速率，以便使接收者來得及接收	防止過多的數據注入到網絡中，避免出現網絡負載過大的狀況
實現方法	滑動窗口	慢開始、擁塞避免 快重傳、快恢復
區別	點對點通訊量的控制，發送方和接收方有關	整個網絡，全局性的過程

若是發送者發送數據過快，接收者來不及接收，那麼就會有分組丟失。爲了不分組丟失，控制發送者的發送速度，使得接收者來得及接收，這就是流量控制。流量控制根本目的是防止分組丟失，它是構成TCP可靠性的一方面。 由滑動窗口協議（連續ARQ協議）實現。滑動窗口協議既保證了分組無差錯、有序接收，也實現了流量控制。主要的方式就是接收方返回的 ACK 中會包含本身的接收窗口的大小，而且利用大小來控制發送方的數據發送。 流量控制引起的死鎖？怎麼避免死鎖的發生？ 當發送者收到了一個窗口爲0的應答，發送者便中止發送，等待接收者的下一個應答。可是若是這個窗口不爲0的應答在傳輸過程丟失，發送者一直等待下去，而接收者覺得發送者已經收到該應答，等待接收新數據，這樣雙方就相互等待，從而產生死鎖。 爲了不流量控制引起的死鎖，TCP使用了持續計時器。每當發送者收到一個零窗口的應答後就啓動該計時器。時間一到便主動發送報文詢問接收者的窗口大小。若接收者仍然返回零窗口，則重置該計時器繼續等待；若窗口不爲0，則表示應答報文丟失了，此時重置發送窗口後開始發送，這樣就避免了死鎖的產生。