總結回顧html
這篇文章你會了解到什麼git
做用:它是與其餘計算機進行通訊的應用,它是對應應用程序的通訊服務的。各類應用軟件,包括web應用。github
協議:DNS、FTP、HTTP、SMTP、TELNET、IRC、WHOISweb
做用:這一層的主要做用是定義數據格式和加密。面試
做用:控制應用程序的會話能力,它定義了一段會話的開始、控制和結束,包括對多個雙向消息的控制和管理,以便在只完成一部分消息時能夠通知應用。算法
PS:其實在應用層、表示層、會話層這三層中,協議是能夠共用的 數組
做用:對差錯恢復協議和無差錯恢復協議的選擇,對同一主機上不一樣數據流的輸入進行復用,對數據包進行從新排序。是最關鍵的一層,是惟一負責總體的數據傳輸和數據控制的。對上三層提供可靠的傳輸服務,對網絡層提供可靠的目的地信息。在這一層數據的單位被稱爲數據段。緩存
協議:TCP、UDP等安全
做用:主要負責尋找地址和路由選擇,網絡層還能夠實現阻塞控制、網際互聯等。cookie
協議:IP、IPX、RIP、OSPF等
做用:負責物理層面上的互聯的、節點間的通訊傳輸;該層的做用包括:物理地址尋址、數據的成幀、流量控制、數據的檢錯、重發等。在這一層,數據的單位稱爲幀(frame)
協議:ARP、RARP、SDLC、HDLC、PPP、STP、幀中繼等
做用:負責0、1 比特流(0/1序列)與電壓的高低、逛的閃滅之間的轉換 規定了激活、維持、關閉通訊端點之間的機械特性、電氣特性、功能特性以及過程特性;該層爲上層協議提供了一個傳輸數據的物理媒體。在這一層,數據的單位稱爲比特(bit)。
典型規範:EIA/TIA RS-23二、EIA/TIA RS-44九、V.3五、RJ-4五、fddi令牌環網等
OSI:
TCP/IP:
計算機與網絡設備要互相通訊,雙方須要基於相同的方法。好比如何創建通訊目標,如何創建通訊鏈接,由那一邊先發起通訊,使用何種語言進行通訊,什麼時候斷開,這些都須要事先確認好。不一樣設備、不一樣操做系統之間也須要確認規則,咱們稱這些規則爲協議。
TCP/IP是互聯網相關協議的統稱,包含:TCP,DUP,IP,FTP,HTTP,SMTP等等協議。
TCP/IP 模型是互聯網的基礎,它是一系列網絡協議的總稱。這些協議能夠劃分爲四層,分別爲鏈路層、網絡層、傳輸層和應用層。
在網絡體系結構中網絡通訊的創建必須是在通訊雙方的對等層進行,不能交錯。 在整個數據傳輸過程當中,數據在發送端時通過各層時都要附加上相應層的協議頭和協議尾(僅數據鏈路層須要封裝協議尾)部分,也就是要對數據進行協議封裝,以標識對應層所用的通訊協議。接下去介紹 TCP/IP 中有兩個具備表明性的傳輸層協議----TCP 和 UDP。
UDP全稱是用戶數據協議,UDP是處於傳輸層的協議。和TCP同樣是處理數據包的。UDP是面向無鏈接的。UDP不提供數據分組和組裝,也不對數據進行重排,不保證數據是否安全到達。
UDP是一種面向無鏈接的協議,在發送數據以前,它不須要想TCP同樣須要三次握手創建鏈接,想發送數據就能夠發送,它只是數據的搬用工,不會對數據進行任何的拆分和組裝。
基於UDP是面試無鏈接的,不須要創建鏈接,想何時發送數據均可以發,因此,UDP是不可靠的。而且接受到什麼數據就傳遞什麼數據,並不會進行數據的備份。發送數據方並不關心數據是夠丟失,也不關心接收方是夠正確接收數據。 而後網絡時好時壞,可是UDP協議沒有網絡阻塞的功能,若是數據開始發送,就會以一種恆定的速度開始發送數據。即便在網絡很差的狀況下,也不會進行速度的調整,這樣會致使,在網絡狀況通常時,發生數據丟包。
UDP以恆定的速度發送數據,在網絡狀況不佳的狀況下,是不可靠的,可是正是因爲這樣的不可靠性,致使UDP沒有TCP那麼複雜,不須要去保證數據的準確到達,也不須要重發,更不行考慮數據丟包的狀況。
UDP頭部包含:
因此,DUP的頭部開銷小,只有八個字節,相比TCP的二十幾個字節在數據傳輸時,是很是高效的。
UDP不僅支持一對一的傳輸方式,還支持一對多、多對多、多對一的傳輸方式。換句話說,UDP提供了單播、多播、廣播的傳輸方式。
在數據發送時,UDP只是對應用層數據進行UDP頭部表示就傳遞給IP網絡層,而且不會對數據進行分組、拆分和封裝,保留報文的邊界,那麼須要應用程序選擇合適的報文大小。
使用場景:直播,遊戲,等大機率會使用UDP,若是使用TCP,可能會出現極差的用戶體驗。TCP保證數據的準確和正確,若是網絡出現波動,數據傳輸慢,等到數據傳到過來時,可能已經發生了不少事情,用戶的畫面不是最新,已然是不能知足用戶訴求。
當計算機進行通訊時,兩臺計算機不少時候須要保證數據的可靠安全正確。例如,當你查看郵寄或者訪問一個網頁時,若是你不但願你看見的網頁或者郵寄是完整的,沒有丟失內容,那麼這裏須要使用到TCP。
TCP全稱是傳輸控制協議,是一種面向有鏈接、安全可靠的、基礎字節流的傳輸控制協議。
在發送數據以前,雙方須要創建鏈接,才能進行數據的正常發送。
每條TCP傳輸只能在兩個端點,只能進行點對點的傳輸,不支持多播和廣播。
TCP不像UDP那樣一個報文一個報文獨立傳輸,而是在不保存報文邊界的狀況下以字節流的形式傳輸。
TCP爲了保證傳輸的可靠性給每個包一個序號,同時也保證了傳輸到接收方的包是按序排列。接收方對於已經接受的包會回傳一個相應的確認(ACK),若是發送方在確認的往返時延(RTT)沒有收到確認,就會從新發送。
當網絡出現阻塞的時候,TCP會減小發送數量和發送速率。
TCP容許通訊的雙方應用程序在任什麼時候候發送數據,由於TCP在兩端都設有緩存,來存放臨時通訊數據。TCP能夠立刻發送數據段,也能夠緩存等待一段時候在發數據段,以便一次發送更多的數據(最大的數據段取決於MSS)。
起初客戶端和服務端是都出關閉的狀態,在通訊開始前,雙方會創建TCB,客戶端在創建以後進行準備發送階段,服務端處於LISTEN狀態。
客服端發送請求鏈接報文段,其中包括自身的數據通訊初始碼。在請求發送以後,客戶端進去了SYN-SENT狀態。
服務端接受到請求鏈接報文,若是贊成鏈接,這服務端回覆一個報文段,其中也會包含一個自身的數據通訊數據碼。在發送後,便進入了SYN-RECEIVED狀態。
客戶端接受到服務端的報文段。還要向服務端發送一個確認報文。客戶端在發送完成以後就進行了ESTABLISHED狀態,服務端在接受到這個請求後也進行ESTABLISHED狀態。此時客戶端服務端創建鏈接完成。
PS:第三次握手中能夠包含數據,經過快速打開(TFO)技術就能夠實現這一功能。其實只要涉及到握手的協議,均可以使用相似 TFO 的方式,客戶端和服務端存儲相同的 cookie,下次握手時發出 cookie 達到減小 RTT 的目的。
PS:兩次握手就能夠完成,爲撒須要三次了? 由於這是爲了防止出現失效的鏈接請求報文段被服務端接收的狀況,從而產生錯誤。 能夠想象以下場景。客戶端發送了一個鏈接請求 A,可是由於網絡緣由形成了超時,這時 TCP 會啓動超時重傳的機制再次發送一個鏈接請求 B。此時請求順利到達服務端,服務端應答完就創建了請求,而後接收數據後釋放了鏈接。 假設這時候鏈接請求 A 在兩端關閉後終於抵達了服務端,那麼此時服務端會認爲客戶端又須要創建 TCP 鏈接,從而應答了該請求並進入 ESTABLISHED 狀態。可是客戶端實際上是 CLOSED 的狀態,那麼就會致使服務端一直等待,形成資源的浪費。
PS:在創建鏈接中,任意一端掉線,TCP 都會重發 SYN 包,通常會重試五次,在創建鏈接中可能會遇到 SYN Flood 攻擊。遇到這種狀況你能夠選擇調低重試次數或者乾脆在不能處理的狀況下拒絕請求。
如客戶端認爲數據發送完成,須要向服務端發送釋放鏈接的請求。客戶端進入FIN_WAIT_1狀態。
服務端接收到客戶端的鏈接釋放請求,會告訴應用層要釋放TCP鏈接。而後發送ACK到客戶端,而後進入CLOSE_WAIT狀態。此時代表客戶端到服務端的鏈接已經釋放,不會接受來自客戶端的數據了,可是因爲TCP是全雙工。因此此時服務端還能夠向客戶端發送數據。
服務端若是在此時數據尚未發送完成,會繼續發送,在數據發送完畢以後。服務端會向客戶端發送鏈接釋放的請求。而後服務端進入LAST_ACK狀態。
客戶端在接受到服務端的釋放請求。會向服務端在發送一個確認請求。此時客戶端進入TIME_WAIT狀態 該狀態會持續 2MSL(最大段生存期,指報文段在網絡中生存的時間,超時會被拋棄) 時間,若該時間段內沒有 服務端的重發請求的話,就進入 CLOSED 狀態。當 客戶端收到確認應答後,也便進入 CLOSED 狀態。
PS:爲何 A 要進入 TIME-WAIT 狀態,等待 2MSL 時間後才進入 CLOSED 狀態? 爲了保證 B 能收到 A 的確認應答。若 A 發完確認應答後直接進入 CLOSED 狀態,若是確認應答由於網絡問題一直沒有到達,那麼會形成 B 不能正常關閉。
ARQ協議就是超時重傳機制。經過確認和超時機制保證數據的正確到達,是OSI模型中傳輸層和數據鏈路層的錯誤糾正協議之一,在不可靠的服務基礎上實現可靠的信息傳輸。ARQ協議包含中止等待ARQ協議和連續ARQ協議,擁有錯誤檢測,正面確認,超時重傳和負面確認及重傳等機制。
TCP是全雙工協議,就是在創建鏈接以後,雙方就是發送方也是接收方。在只考慮只是一方發送一方接收的狀況下。咱們假設發送方爲A,接收方爲B。
A發送報文分組M1,發送完畢就暫停發送,等待B的確認。B收到M1,就向A發送確認。A收到確認以後就在發送下一個分組M2。
若是A發送過程當中出現差錯或者B在接收M1是檢查到出了差錯(這裏A在發送以前會保存分組的副本,再只有在收到確認以後纔會清除副本),B在接收M1時檢測到差錯就丟棄M1,其餘什麼都不作。出現差錯的狀況,A只要超過一段時間沒有收到確認,就職務出現差錯,就會從新發送剛剛的分組,也就是超時重傳。
超時重傳就是在A發送完一個分組以後,就會設置一個超時計時器,若是在超時時間大於這個時間,就會從新發送分組。固然若是在時間內收到確認信息就不會從新發送。通常超時計時器的時間應該是大於一個RTT時間。
若是A向B發送了分組M1,B接收到M1以後,發送確認應答信息,可是因爲網絡問題,確認信息丟失,那麼這個時間,A在超時重傳的時間段內,沒有收到B 的確認信息。A會重傳M1分組。那麼B會作兩個動做,①B會丟棄到M1分組,不向上層交付 ,由於以前已經收到過M1分組。②向A發送確認信息。
還有一種狀況就是B發送的確認信息超時了,在超時重傳的時間以後到達A,這種狀況下,A會丟棄確認信息,而後重發分組,B在接收到信息以後,會丟棄重複的分組。並重發確認信息。中止等待ARQ協議的優勢是簡答,但也有很嚴重的肯定,就是信道利用率過低。 信道利用率U = TD / (TD + RTT + TA)。 其中Td發送時延,RTT是一個往返時間,Ta是接收時延
因爲中止等待ARQ協議通道利用率過低,全部須要使用連續ARQ協議來進行改善。這個協議會連續發送一組數據包。而後等待這些數據包的ACK。
連續ARQ協議規定,發送方每收到一個確認,就把發送窗口向前滑動一個分組的位置。當發送方收到第一個分組的確認,就把發送窗口向前移動一個分組的位置。若是原來已經發送了前5個分組,則如今能夠發送窗口內的第6個分組。
接收方通常都是採用累積確認的方式。也就是說接收方沒必要對收到的分組逐個發送確認。而是在收到幾個分組後,對按序到達的最後一個分組發送確認。若是收到了這個分組確認信息,則表示到這個分組爲止的全部分組都已經正確接收到了。
累積確認的優勢是容易實現,即便確認丟失也沒必要重傳。但缺點是,不能正確的向發送方反映出接收方已經正確收到的全部分組的信息。好比發送方發送了前5個分組,而中間的第3個分組丟失了,這時候接收方只能對前2個發出確認。而不知道後面3個分組的下落,所以只能把後面的3個分組都重傳一次,這種機制叫Go-back-N(回退N),表示須要再退回來重傳已發送過的N個分組。
滑動窗口協議在在發送方和接收方之間各自維持一個滑動窗口,發送發是發送窗口,接收方是接收窗口,並且這個窗口是隨着時間變化能夠向前滑動的。它容許發送方發送多個分組而不需等待確認。TCP的滑動窗口是以字節爲單位的。
發送窗口中有四個概念:
滑動窗口是一個很重要的概念,它幫助 TCP 實現了流量控制的功能。接收方經過報文告知發送方還能夠發送多少數據,從而保證接收方可以來得及接收數據,防止出現接收方帶寬已滿,可是發送方還一直髮送數據的狀況。
網絡擁塞現象是指到達通訊網絡中某一部分的分組數量過多,使得該部分網絡來不及處理,以至引發這部分乃至整個網絡性能降低的現象,嚴重時甚至會致使網絡通訊業務陷入停頓,即出現死鎖現象。擁塞控制是處理網絡擁塞現象的一種機制。
擁塞控制是一種用來調整傳輸控制協議(TCP)鏈接上單次發送的分組數量的算法,經過增減單次發送量逐步調整,使之逼近當前網絡的承載量。若是單次發送量爲1,此協議就退化爲停等協議。單次發送量是以字節來作單位的;可是若是假設TCP每次傳輸都是按照最大報文段(MSS)來發送數據的,那麼也能夠把數據包個數看成單次發送量的單位,因此有時咱們說單次發送量增長1也就是增長至關於1個最大報文段的字節數。
擁塞控制假設分組的丟失都是由網絡繁忙形成的。擁塞控制有三種動做,分別對應到源主機感覺到的狀況:
收到一條新確認。代表當前的單次發送量小於網絡的承載量。此時能夠增長單次發送量。若當前單次發送量小於慢啓動閾值(ssthreash),則單次發送量加倍(乘以2),即指數增加;不然單次發送量加1,即線性增加。
收到三條對同一分組的確認,即三條重複的確認。說明網絡有一點兒繁忙。此時單次發送量減半,慢啓動閾值(ssthreash)約等於單次發送量,進入線性增加階段。
對某一個分組的確認遲遲未到,即超時。說明網絡比上一狀況中的更加繁忙。此時慢啓動閾值=單次發送量÷2,單次發送量=1,進入慢啓動階段(指數增加階段)。
慢啓動,是傳輸控制協議(TCP)使用的一種阻塞控制機制。慢啓動也叫作指數增加期。 慢啓動算法經過觀察到新分組進入網絡的速率應該與另外一端返回確認的速率相同而進行工做。
慢啓動爲發送方的TCP增長了另外一個窗口:擁塞窗口(congestion window),記爲cwnd。擁塞窗口是發送方使用的流量控制,而通告窗口則是接收方使用的流量控制。算法描述以下:
當與另外一個網絡的主機創建TCP鏈接時,擁塞窗口被初始化爲1個報文段(即另外一端通告的報文段大小)。
每收到一個ACK,擁塞窗口就翻倍(cwnd以字節爲單位,可是慢啓動以報文段大小爲單位進行增長)。這是一種指數增加的關係。
發送方取擁塞窗口與通告窗口中的最小值做爲發送上限。
慢啓動算法是在一個鏈接上發起數據流的方法,其指數級增加很快就會使網絡出現擁塞現象,由於某些點上可能達到了互聯網的容量,因而中間路由器開始丟棄分組。擁塞避免算法是一種處理丟失分組的方法。有兩種分組丟失的指示:發生超時和接收到重複的確認。發生超時,指源主機在超時定時器溢出時沒有收到目的主機對某一分組的ACK;接收到重複確認,指在源主機的超時定時器溢出前,連續收到3個或3個以上收對某一分組的ACK。
當發現超時或接收到3次重複確認時,則表示有丟包事件,此時網絡已發生擁塞現象,要進行相應的擁塞控制。算法描述以下:
將慢啓動閾值(ssthreash)設置爲當前窗口的一半(cwnd 和通告窗口大小的最小值,但最小爲2個報文)。
若是是超時引發的擁塞,則擁塞窗口(cwmd)被置爲1,進入慢啓動過程。若是是重複確認引發的擁塞,則進入快速重傳和快速恢復過程。
進入慢啓動階段後,擁塞窗口會指數級增加,若是擁塞窗口大於慢啓動閾值(ssthreash),執行擁塞避免算法。執行擁塞避免算法時,因爲慢啓動閾值(ssthreash)已經存在,擁塞窗口大小再也不翻倍增加,而是線性增長。
擁塞避免算法和慢啓動算法是兩個目的不一樣、獨立的算法。可是當擁塞發生時,咱們但願下降分組進入網絡的傳輸速率,因而能夠調用慢啓動來做到這一點。在實際中這兩個算法一般在一塊兒實現。1990年出現的TCPReno版本增長了 「快速重傳」算法、」快速恢復」算法,避免了當網絡擁塞不夠嚴重時採用」慢啓動」算法而形成過大地減少發送窗口尺寸的現象。
目的主機在收到一個失序的報文段時,會當即產生一個ACK(重複的ACK),這個重複的ACK不該該被延遲,目的在於讓源主機知道目的主機收到了一個失序的報文段,並告訴源主機本身但願收到的序號。
因爲咱們不知道一個重複的ACK是由一個丟失的報文段引發的,仍是因爲僅僅出現了幾個報文段的從新排序,所以咱們等待少許重複的ACK到來。假如這只是一些報文段的從新排序,則在從新排序的報文段被處理併產生一個新的ACK以前,只可能產生1到2個重複的ACK。若是一連串收到3個或3個以上的重複ACK,就很是多是一個報文段丟失了,進入快速重傳過程,描述以下:
1.將慢啓動閾值(ssthreash)設置爲當前擁塞窗口(cwnd)的一半,設置擁塞窗口(cwnd)爲慢啓動閾值(ssthreash)加上3倍的報文段大小。重傳丟失的數據報文段,而無需等待超時定時器溢出。
2.每次收到另外一個重複的ACK時,cwnd增長一個報文段大小併發送1個分組(若是新的cwnd容許發送)。收到另外一個重複的ACK,說明網絡中傳輸的一個分組到達了目的主機,網絡中可再容納一個分組,故cwnd增長一個報文段大小併發送一個分組。
丟失的分組經過快速重傳過程發送完,並被目的主機接受後,目的主機就再也不發送重複的ACK通知源主機發送丟失的分組了,而是發送確認新數據的ACK通知源主機發送新的分組。這個ACK應該是在進行重傳後的一個往返時間內對重傳分組的確認,也應該是對丟失的分組和收到的第1個重複的ACK之間的全部中間報文段的確認。此時爲了快速的恢復到較高的傳輸速度,就會進入快速恢復階段,算法描述以下:
參考