當前位置:首頁 » 網路連接 » 計算機網路應用層rtt
擴展閱讀
新倩女幽魂顯示網路異常 2025-09-29 06:03:47
蘋果一鍵網路設置 2025-09-29 06:02:22

計算機網路應用層rtt

發布時間: 2023-05-01 11:15:48

計算機網路知識點

一、計算機網路概述

1.1 計算機網路的分類

按照網路的作用范圍:廣域網(WAN)、城域網(MAN)、區域網(LAN);

按照網路使用者:公用網路、專用網路。

1.2 計算機網路的層次結構

TCP/IP四層模型與OSI體系結構對比:

1.3 層次結構設計的基本原則

各層之間是相互獨立的;

每一層需要有足夠的靈活性;

各層之間完全解耦。

1.4 計算機網路的性能指標

速率:bps=bit/s 時延:發送時延、傳播時延、排隊時延、處理時延 往返時間RTT:數據報文在端到端通信中的來回一次的時間。

二、物理層

物理層的作用:連接不同的物理設備,傳輸比特流。該層為上層協議提供了一個傳輸數據的可靠的物理媒體。簡單的說,物理層確保原始的數據可在各種物理媒體上傳輸。

物理層設備:

中繼器【Repeater,也叫放大器】:同一區域網的再生信號;兩埠的網段必須同一協議;5-4-3規程:10BASE-5乙太網中,最多串聯4個中繼器,5段中只能有3個連接主機;

集線器:同一區域網的再生、放大信號(多埠的中繼器);半雙工,不能隔離沖突域也不能隔離廣播域。

信道的基本概念:信道是往一個方向傳輸信息的媒體,一條通信電路包含一個發送信道和一個接受信道。

單工通信信道:只能一個方向通信,沒有反方向反饋的信道;

半雙工通信信道:雙方都可以發送和接受信息,但不能同時發送也不能同時接收;

全雙工通信信道:雙方都可以同時發送和接收。

三、數據鏈路層

3.1 數據鏈路層概述

數據鏈路層在物理層提供的服務的基礎上向網路層提供服務,其最基本的服務是將源自網路層來的數據可靠地傳輸到相鄰節點的目標機網路層。數據鏈路層在不可靠的物理介質上提供可靠的傳輸。

該層的作用包括: 物理地址定址、數據的成幀、流量控制、數據的檢錯、重發 等。

有關數據鏈路層的重要知識點:

數據鏈路層為網路層提供可靠的數據傳輸;

基本數據單位為幀;

主要的協議:乙太網協議;

兩個重要設備名稱:網橋和交換機。

封裝成幀:「幀」是 數據鏈路層 數據的基本單位:

透明傳輸:「透明」是指即使控制字元在幀數據中,但是要當做不存在去處理。即在控制字元前加上轉義字元ESC。

3.2 數據鏈路層的差錯監測

差錯檢測:奇偶校驗碼、循環冗餘校驗碼CRC

奇偶校驗碼–局限性:當出錯兩位時,檢測不到錯誤。

循環冗餘檢驗碼:根據傳輸或保存的數據而產生固定位數校驗碼。

3.3 最大傳輸單元MTU

最大傳輸單元MTU(Maximum Transmission Unit),數據鏈路層的數據幀不是無限大的,數據幀長度受MTU限制.

路徑MTU:由鏈路中MTU的最小值決定。

3.4 乙太網協議詳解

MAC地址:每一個設備都擁有唯一的MAC地址,共48位,使用十六進製表示。

乙太網協議:是一種使用廣泛的區域網技術,是一種應用於數據鏈路層的協議,使用乙太網可以完成相鄰設備的數據幀傳輸:

區域網分類:

Ethernet乙太網IEEE802.3:

乙太網第一個廣泛部署的高速區域網

乙太網數據速率快

乙太網硬體價格便宜,網路造價成本低

乙太網幀結構:

類型:標識上層協議(2位元組)

目的地址和源地址:MAC地址(每個6位元組)

數據:封裝的上層協議的分組(46~1500位元組)

CRC:循環冗餘碼(4位元組)

乙太網最短幀:乙太網幀最短64位元組;乙太網幀除了數據部分18位元組;數據最短46位元組;

MAC地址(物理地址、區域網地址)

MAC地址長度為6位元組,48位;

MAC地址具有唯一性,每個網路適配器對應一個MAC地址;

通常採用十六進製表示法,每個位元組表示一個十六進制數,用 - 或 : 連接起來;

MAC廣播地址:FF-FF-FF-FF-FF-FF。

四、網路層

網路層的目的是實現兩個端系統之間的數據透明傳送,具體功能包括定址和路由選擇、連接的建立、保持和終止等。數據交換技術是報文交換(基本上被分組所替代):採用儲存轉發方式,數據交換單位是報文。

網路層中涉及眾多的協議,其中包括最重要的協議,也是TCP/IP的核心協議——IP協議。IP協議非常簡單,僅僅提供不可靠、無連接的傳送服務。IP協議的主要功能有:無連接數據報傳輸、數據報路由選擇和差錯控制。

與IP協議配套使用實現其功能的還有地址解析協議ARP、逆地址解析協議RARP、網際網路報文協議ICMP、網際網路組管理協議IGMP。具體的協議我們會在接下來的部分進行總結,有關網路層的重點為:

1、網路層負責對子網間的數據包進行路由選擇。此外,網路層還可以實現擁塞控制、網際互連等功能;

2、基本數據單位為IP數據報;

3、包含的主要協議:

IP協議(Internet Protocol,網際網路互聯協議);

ICMP協議(Internet Control Message Protocol,網際網路控制報文協議);

ARP協議(Address Resolution Protocol,地址解析協議);

RARP協議(Reverse Address Resolution Protocol,逆地址解析協議)。

4、重要的設備:路由器

路由器相關協議

4.1 IP協議詳解

IP網際協議是 Internet 網路層最核心的協議。虛擬互聯網路的產生:實際的計算機網路錯綜復雜;物理設備通過使用IP協議,屏蔽了物理網路之間的差異;當網路中主機使用IP協議連接時,無需關注網路細節,於是形成了虛擬網路。

IP協議使得復雜的實際網路變為一個虛擬互聯的網路;並且解決了在虛擬網路中數據報傳輸路徑的問題。

其中,版本指IP協議的版本,佔4位,如IPv4和IPv6;首部位長度表示IP首部長度,佔4位,最大數值位15;總長度表示IP數據報總長度,佔16位,最大數值位65535;TTL表示IP數據報文在網路中的壽命,佔8位;協議表明IP數據所攜帶的具體數據是什麼協議的,如TCP、UDP。

4.2 IP協議的轉發流程

4.3 IP地址的子網劃分

A類(8網路號+24主機號)、B類(16網路號+16主機號)、C類(24網路號+8主機號)可以用於標識網路中的主機或路由器,D類地址作為組廣播地址,E類是地址保留。

4.4 網路地址轉換NAT技術

用於多個主機通過一個公有IP訪問訪問互聯網的私有網路中,減緩了IP地址的消耗,但是增加了網路通信的復雜度。

NAT 工作原理:

從內網出去的IP數據報,將其IP地址替換為NAT伺服器擁有的合法的公共IP地址,並將替換關系記錄到NAT轉換表中;

從公共互聯網返回的IP數據報,依據其目的的IP地址檢索NAT轉換表,並利用檢索到的內部私有IP地址替換目的IP地址,然後將IP數據報轉發到內部網路。

4.5 ARP協議與RARP協議

地址解析協議 ARP(Address Resolution Protocol):為網卡(網路適配器)的IP地址到對應的硬體地址提供動態映射。可以把網路層32位地址轉化為數據鏈路層MAC48位地址。

ARP 是即插即用的,一個ARP表是自動建立的,不需要系統管理員來配置。

RARP(Reverse Address Resolution Protocol)協議指逆地址解析協議,可以把數據鏈路層MAC48位地址轉化為網路層32位地址。

4.6 ICMP協議詳解

網際控制報文協議(Internet Control Message Protocol),可以報告錯誤信息或者異常情況,ICMP報文封裝在IP數據報當中。

ICMP協議的應用:

Ping應用:網路故障的排查;

Traceroute應用:可以探測IP數據報在網路中走過的路徑。

4.7網路層的路由概述

關於路由演算法的要求:正確的完整的、在計算上應該盡可能是簡單的、可以適應網路中的變化、穩定的公平的。

自治系統AS: 指處於一個管理機構下的網路設備群,AS內部網路自治管理,對外提供一個或多個出入口,其中自治系統內部的路由協議為內部網關協議,如RIP、OSPF等;自治系統外部的路由協議為外部網關協議,如BGP。

靜態路由: 人工配置,難度和復雜度高;

動態路由:

鏈路狀態路由選擇演算法LS:向所有隔壁路由發送信息收斂快;全局式路由選擇演算法,每個路由器計算路由時,需構建整個網路拓撲圖;利用Dijkstra演算法求源端到目的端網路的最短路徑;Dijkstra(迪傑斯特拉)演算法

距離-向量路由選擇演算法DV:向所有隔壁路由發送信息收斂慢、會存在迴路;基礎是Bellman-Ford方程(簡稱B-F方程);

4.8 內部網關路由協議之RIP協議

路由信息協議 RIP(Routing Information Protocol)【應用層】,基於距離-向量的路由選擇演算法,較小的AS(自治系統),適合小型網路;RIP報文,封裝進UDP數據報。

RIP協議特性:

RIP在度量路徑時採用的是跳數(每個路由器維護自身到其他每個路由器的距離記錄);

RIP的費用定義在源路由器和目的子網之間;

RIP被限制的網路直徑不超過15跳;

和隔壁交換所有的信息,30主動一次(廣播)。

4.9 內部網關路由協議之OSPF協議

開放最短路徑優先協議 OSPF(Open Shortest Path First)【網路層】,基於鏈路狀態的路由選擇演算法(即Dijkstra演算法),較大規模的AS ,適合大型網路,直接封裝在IP數據報傳輸。

OSPF協議優點:

安全;

支持多條相同費用路徑;

支持區別化費用度量;

支持單播路由和多播路由;

分層路由。

RIP與OSPF的對比(路由演算法決定其性質):

4.10外部網關路由協議之BGP協議

BGP(Border Gateway Protocol)邊際網關協議【應用層】:是運行在AS之間的一種協議,尋找一條好路由:首次交換全部信息,以後只交換變化的部分,BGP封裝進TCP報文段.

五、傳輸層

第一個端到端,即主機到主機的層次。傳輸層負責將上層數據分段並提供端到端的、可靠的或不可靠的傳輸。此外,傳輸層還要處理端到端的差錯控制和流量控制問題。

傳輸層的任務是根據通信子網的特性,最佳的利用網路資源,為兩個端系統的會話層之間,提供建立、維護和取消傳輸連接的功能,負責端到端的可靠數據傳輸。在這一層,信息傳送的協議數據單元稱為段或報文。

網路層只是根據網路地址將源結點發出的數據包傳送到目的結點,而傳輸層則負責將數據可靠地傳送到相應的埠。

有關網路層的重點:

傳輸層負責將上層數據分段並提供端到端的、可靠的或不可靠的傳輸以及端到端的差錯控制和流量控制問題;

包含的主要協議:TCP協議(Transmission Control Protocol,傳輸控制協議)、UDP協議(User Datagram Protocol,用戶數據報協議);

重要設備:網關。

5.1 UDP協議詳解

UDP(User Datagram Protocol: 用戶數據報協議),是一個非常簡單的協議。

UDP協議的特點:

UDP是無連接協議;

UDP不能保證可靠的交付數據;

UDP是面向報文傳輸的;

UDP沒有擁塞控制;

UDP首部開銷很小。

UDP數據報結構:

首部:8B,四欄位/2B【源埠 | 目的埠 | UDP長度 | 校驗和】 數據欄位:應用數據

5.2 TCP協議詳解

TCP(Transmission Control Protocol: 傳輸控制協議),是計算機網路中非常復雜的一個協議。

TCP協議的功能:

對應用層報文進行分段和重組;

面向應用層實現復用與分解;

實現端到端的流量控制;

擁塞控制;

傳輸層定址;

對收到的報文進行差錯檢測(首部和數據部分都檢錯);

實現進程間的端到端可靠數據傳輸控制。

TCP協議的特點:

TCP是面向連接的協議;

TCP是面向位元組流的協議;

TCP的一個連接有兩端,即點對點通信;

TCP提供可靠的傳輸服務;

TCP協議提供全雙工通信(每條TCP連接只能一對一);

5.2.1 TCP報文段結構:

最大報文段長度:報文段中封裝的應用層數據的最大長度。

TCP首部:

序號欄位:TCP的序號是對每個應用層數據的每個位元組進行編號

確認序號欄位:期望從對方接收數據的位元組序號,即該序號對應的位元組尚未收到。用ack_seq標識;

TCP段的首部長度最短是20B ,最長為60位元組。但是長度必須為4B的整數倍

TCP標記的作用:

5.3 可靠傳輸的基本原理

基本原理:

不可靠傳輸信道在數據傳輸中可能發生的情況:比特差錯、亂序、重傳、丟失

基於不可靠信道實現可靠數據傳輸採取的措施:

差錯檢測:利用編碼實現數據包傳輸過程中的比特差錯檢測 確認:接收方向發送方反饋接收狀態 重傳:發送方重新發送接收方沒有正確接收的數據 序號:確保數據按序提交 計時器:解決數據丟失問題;

停止等待協議:是最簡單的可靠傳輸協議,但是該協議對信道的利用率不高。

連續ARQ(Automatic Repeat reQuest:自動重傳請求)協議:滑動窗口+累計確認,大幅提高了信道的利用率。

5.3.1TCP協議的可靠傳輸

基於連續ARQ協議,在某些情況下,重傳的效率並不高,會重復傳輸部分已經成功接收的位元組。

5.3.2 TCP協議的流量控制

流量控制:讓發送方發送速率不要太快,TCP協議使用滑動窗口實現流量控制。

5.4 TCP協議的擁塞控制

擁塞控制與流量控制的區別:流量控制考慮點對點的通信量的控制,而擁塞控制考慮整個網路,是全局性的考慮。擁塞控制的方法:慢啟動演算法+擁塞避免演算法。

慢開始和擁塞避免:

【慢開始】擁塞窗口從1指數增長;

到達閾值時進入【擁塞避免】,變成+1增長;

【超時】,閾值變為當前cwnd的一半(不能<2);

再從【慢開始】,擁塞窗口從1指數增長。

快重傳和快恢復:

發送方連續收到3個冗餘ACK,執行【快重傳】,不必等計時器超時;

執行【快恢復】,閾值變為當前cwnd的一半(不能<2),並從此新的ssthresh點進入【擁塞避免】。

5.5 TCP連接的三次握手(重要)

TCP三次握手使用指令:

面試常客:為什麼需要三次握手?

第一次握手:客戶發送請求,此時伺服器知道客戶能發;

第二次握手:伺服器發送確認,此時客戶知道伺服器能發能收;

第三次握手:客戶發送確認,此時伺服器知道客戶能收。

建立連接(三次握手):

第一次: 客戶向伺服器發送連接請求段,建立連接請求控制段(SYN=1),表示傳輸的報文段的第一個數據位元組的序列號是x,此序列號代表整個報文段的序號(seq=x);客戶端進入 SYN_SEND (同步發送狀態);

第二次: 伺服器發回確認報文段,同意建立新連接的確認段(SYN=1),確認序號欄位有效(ACK=1),伺服器告訴客戶端報文段序號是y(seq=y),表示伺服器已經收到客戶端序號為x的報文段,准備接受客戶端序列號為x+1的報文段(ack_seq=x+1);伺服器由LISTEN進入SYN_RCVD (同步收到狀態);

第三次: 客戶對伺服器的同一連接進行確認.確認序號欄位有效(ACK=1),客戶此次的報文段的序列號是x+1(seq=x+1),客戶期望接受伺服器序列號為y+1的報文段(ack_seq=y+1);當客戶發送ack時,客戶端進入ESTABLISHED 狀態;當服務收到客戶發送的ack後,也進入ESTABLISHED狀態;第三次握手可攜帶數據;

5.6 TCP連接的四次揮手(重要)

釋放連接(四次揮手)

第一次: 客戶向伺服器發送釋放連接報文段,發送端數據發送完畢,請求釋放連接(FIN=1),傳輸的第一個數據位元組的序號是x(seq=x);客戶端狀態由ESTABLISHED進入FIN_WAIT_1(終止等待1狀態);

第二次: 伺服器向客戶發送確認段,確認字型大小段有效(ACK=1),伺服器傳輸的數據序號是y(seq=y),伺服器期望接收客戶數據序號為x+1(ack_seq=x+1);伺服器狀態由ESTABLISHED進入CLOSE_WAIT(關閉等待);客戶端收到ACK段後,由FIN_WAIT_1進入FIN_WAIT_2;

第三次: 伺服器向客戶發送釋放連接報文段,請求釋放連接(FIN=1),確認字型大小段有效(ACK=1),表示伺服器期望接收客戶數據序號為x+1(ack_seq=x+1);表示自己傳輸的第一個位元組序號是y+1(seq=y+1);伺服器狀態由CLOSE_WAIT 進入 LAST_ACK (最後確認狀態);

第四次: 客戶向伺服器發送確認段,確認字型大小段有效(ACK=1),表示客戶傳輸的數據序號是x+1(seq=x+1),表示客戶期望接收伺服器數據序號為y+1+1(ack_seq=y+1+1);客戶端狀態由FIN_WAIT_2進入TIME_WAIT,等待2MSL時間,進入CLOSED狀態;伺服器在收到最後一次ACK後,由LAST_ACK進入CLOSED;

為什麼需要等待2MSL?

最後一個報文沒有確認;

確保發送方的ACK可以到達接收方;

2MSL時間內沒有收到,則接收方會重發;

確保當前連接的所有報文都已經過期。

六、應用層

為操作系統或網路應用程序提供訪問網路服務的介面。應用層重點:

數據傳輸基本單位為報文;

包含的主要協議:FTP(文件傳送協議)、Telnet(遠程登錄協議)、DNS(域名解析協議)、SMTP(郵件傳送協議),POP3協議(郵局協議),HTTP協議(Hyper Text Transfer Protocol)。

6.1 DNS詳解

DNS(Domain Name System:域名系統)【C/S,UDP,埠53】:解決IP地址復雜難以記憶的問題,存儲並完成自己所管轄范圍內主機的 域名 到 IP 地址的映射。

域名解析的順序:

【1】瀏覽器緩存,

【2】找本機的hosts文件,

【3】路由緩存,

【4】找DNS伺服器(本地域名、頂級域名、根域名)->迭代解析、遞歸查詢。

IP—>DNS服務—>便於記憶的域名

域名由點、字母和數字組成,分為頂級域(com,cn,net,gov,org)、二級域(,taobao,qq,alibaba)、三級域(www)(12-2-0852)

6.2 DHCP協議詳解

DHCP(Dynamic Configuration Protocol:動態主機設置協議):是一個區域網協議,是應用UDP協議的應用層協議。作用:為臨時接入區域網的用戶自動分配IP地址。

6.3 HTTP協議詳解

文件傳輸協議(FTP):控制連接(埠21):傳輸控制信息(連接、傳輸請求),以7位ASCII碼的格式。整個會話期間一直打開。

HTTP(HyperText Transfer Protocol:超文本傳輸協議)【TCP,埠80】:是可靠的數據傳輸協議,瀏覽器向伺服器發收報文前,先建立TCP連接,HTTP使用TCP連接方式(HTTP自身無連接)。

HTTP請求報文方式:

GET:請求指定的頁面信息,並返回實體主體;

POST:向指定資源提交數據進行處理請求;

DELETE:請求伺服器刪除指定的頁面;

HEAD:請求讀取URL標識的信息的首部,只返回報文頭;

OPETION:請求一些選項的信息;

PUT:在指明的URL下存儲一個文檔。

6.3.1 HTTP工作的結構

6.3.2 HTTPS協議詳解

HTTPS(Secure)是安全的HTTP協議,埠號443。基於HTTP協議,通過SSL或TLS提供加密處理數據、驗證對方身份以及數據完整性保護

原文地址:https://blog.csdn.net/Royalic/article/details/119985591

② 計算機網路-Http/Https基礎

一、前言

主要包括:1、http基礎:TCP/IP,TCP協議,IP協議,DNS協議,URI與URL;

2、http協議:http報文,http方法,http狀態碼,常見問題

名詞解釋:

(1)HTTP(HyperText Transfer Protocol)超文本傳輸協議

(2)URL(Uniform Resource Locator)統一資源定位符

(3)URI(Uniform Resource Identifer)統一資源標識符

(4)TCP(Transmission Control Protocol)傳輸控制協議

(5)IP(Internet Protocol)網際協議

(6)UDP(User Data Protocol)用戶數據報協議

(7)MAC地址(Media Access Control)媒體訪問控制地址/物理地址/硬體地址

(8)ARP協議(Address Resolution Protocol)地址解析協議

二、HTTP基礎

2.1TCP/IP

TCP/IP是互聯網相關的各類協議族的總稱,而http是TCP/IP協議族中的一個子集。

TCP/IP協議族可以分為四層:

(1)應用層:決定向用戶提供 應用服務時通信的活動 ,TCP/IP協議族內預存了各類通用的應用服務,如:http,ftp,dns等。

(2)傳輸層:提供處於網路連接中的兩台計算機之間的 數據傳輸 ,包含兩個協議:tcp,udp。

(3)網路層:用來處理 網路上流動的數據包 ,在眾多的選項中選擇一條傳輸線路,將數據包傳送到對方計算機。包含的協議:IP協議。

(4)數據鏈路層:用來 處理連接網路的硬體 部分。

2.2 IP協議

IP協議屬於網路層,負責處理網路上流動的數據包。為了保證傳送成功,需要滿足各類條件,其中兩個重要的條件時IP地址和MAC地址。

(1)IP地址,指明了節點被分配到的地址;

(2)MAC地址,指網卡所屬的固定地址;

(3)IP地址可以和MAC地址進行配對,IP地址可以變換,但是MAC地址基本上不會更改;

(4)使用ARP地址解析協議可以根據通信方的IP地址反查出對應的MAC地址

2.3 TCP協議

TCP協議位於傳輸層,提供 可靠的位元組流服務 (也就是說,將大數據分隔成以報文段為單位的數據包進行管理)。

為了確保數據准確無誤的到達目標處,TCP協議通常採用三次握手策略。

如果在握手的過程中某一個階段莫名的 中斷 了, TCP協議會再次以相同的順序發送相同的數據包

2.4DNS協議

DNS協議位於應用層,提供域名到IP地址之間的解析服務。

2.5 URI和URL

URI是某一個協議方案表示的 資源的定位標識符 ,協議方案是指訪問資源所使用的協議類型,如:http,ftp,file等。

URL用字元串標識某一個互聯網資源 ,而 URL表示資源的地點,URL是URI的子集。

2.6 HTTP協議

HTTP協議用於客戶端和伺服器端之間的通信。請求必定由客戶端發出,而伺服器端回復響應。

HTTP協議不保存狀態,為 無狀態協議 。這是為了更快的處理大量事務,確保協議的可伸縮性而特意設計的。

但是隨著Web的不斷發展,這一特性也引發了一些問題,如:如何保持登錄狀態、如何記錄用戶信息等,為了解決這一問題,引入了Cookie技術。

2.6.1常見狀態碼

2XX 成功

200 OK,表示從客戶端發來的請求在伺服器端被正確處理

204 No content,表示請求成功,但響應報文不含實體的主體部分

205 Reset Content,表示請求成功,但響應報文不含實體的主體部分,但是與 204 響應不同在於要求請求方重置內容

206 Partial Content,進行范圍請求

3XX 重定向

301 moved permanently,永久性重定向,表示資源已被分配了新的 URL

302 found,臨時性重定向,表示資源臨時被分配了新的 URL

303 see other,表示資源存在著另一個 URL,應使用 GET 方法獲取資源

304 not modified,表示伺服器允許訪問資源,但因發生請求未滿足條件的情況

307 temporary redirect,臨時重定向,和302含義類似,但是期望客戶端保持請求方法不變向新的地址發出請求

4XX 客戶端錯誤

400 bad request,請求報文存在語法錯誤

401 unauthorized,表示發送的請求需要有通過 HTTP 認證的認證信息

403 forbidden,表示對請求資源的訪問被伺服器拒絕

404 not found,表示在伺服器上沒有找到請求的資源

5XX 伺服器錯誤

500 internal sever error,表示伺服器端在執行請求時發生了錯誤

501 Not Implemented,表示伺服器不支持當前請求所需要的某個功能

503 service unavailable,表明伺服器暫時處於超負載或正在停機維護,無法處理請求

2.6.2HTTP報文頭部(HTTP首部)

| 通用欄位 | ** 作用** |
| Cache-Control | 控制緩存的行為 |
| Connection | 瀏覽器想要優先使用的連接類型,比如:keep-alive |
| Date | 創建報文時間 |
| Pragma | 報文指令 |
| Via | 代理伺服器相關信息 |
| Transfer-Encoding | 傳輸編碼方式 |
| Upgrade | 要求客戶端升級協議 |
| Warning | 在內容中可能存在錯誤 |

| ** 請求欄位** | ** 作用** |
| Accept | 能正確接收的媒體類型 |
| Accept-Charset | 能正確接收的字元集 |
| Accept-Encoding | 能正確接收的編碼格式列表 |
| Accept-Language | 能正確接收的語言列表 |
| Expect | 期待服務端的指定行為 |
| From | 請求方郵箱地址 |
| Host | 伺服器的域名 |
| If-Match | 兩端資源標記比較 |
| If-Modified-Since | 本地資源未修改返回 304(比較時間) |
| If-None-Match | 本地資源未修改返回 304(比較標記) |
| User-Agent | 客戶端信息 |
| Max-Forwards | 限制可被代理及網關轉發的次數 |
| Proxy-Authorization | 向代理伺服器發送驗證信息 |
| Range | 請求某個內容的一部分 |

| Referer | 示瀏覽器所訪問的前一個頁面 |
| TE | 傳輸編碼方式 |

| 響應欄位 | 作用 |
| Accept-Ranges | 是否支持某些種類的范圍 |
| Age | 資源在代理緩存中存在的時間 |
| ETag | 資源標識 |
| Location | 客戶端重定向到某個 URL |
| Proxy-Authenticate | 向代理伺服器發送驗證信息 |
| Server | 伺服器名字 |
| WWW-Authenticate | 獲取資源需要的驗證信息 |

| 實體欄位 | 作用 |
| Allow | 資源的正確請求方式 |
| Content-Encoding | 內容的編碼格式 |
| Content-Language | 內容使用的語言 |
| Content-Length | request body 長度 |
| Content-Location | 返回數據的備用地址 |
| Content-MD5 | Base64加密格式的內容 MD5檢驗值 |
| Content-Range | 內容的位置范圍 |
| Content-Type | 內容的媒體類型 |
| Expires | 內容的過期時間 |
| Last_modified | 內容的最後修改時間 |

2.6.3 HTTP方法

三****、HTTPS基礎

HTTPS 還是通過了 HTTP 來傳輸信息,但是信息通過 TLS 協議進行了加密。

3.1 TLS

TLS 協議位於傳輸層之上,應用層之下。首次進行 TLS 協議傳輸需要兩個 RTT ,接下來可以通過 Session Resumption 減少到一個 RTT。(RTT表示發送端發送數據到接收到對端數據所需的往返時間)

在 TLS 中使用了兩種加密技術,分別為:對稱加密和非對稱加密。

對稱加密:

對稱加密就是兩邊擁有相同的秘鑰,兩邊都知道如何將密文加密解密。

非對稱加密:

有公鑰私鑰之分,公鑰所有人都可以知道,可以將數據用公鑰加密,但是將數據解密必須使用私鑰解密,私鑰只有分發公鑰的一方才知道。

3.2 TLS 握手過程如下圖:

(1)客戶端發送一個隨機值,需要的協議和加密方式

(2)服務端收到客戶端的隨機值,自己也產生一個隨機值,並根據客戶端需求的協議和加密方式來使用對應的方式,發送自己的證書(如果需要驗證客戶端證書需要說明)

(3)客戶端收到服務端的證書並驗證是否有效,驗證通過會再生成一個隨機值,通過服務端證書的公鑰去加密這個隨機值並發送給服務端,如果服務端需要驗證客戶端證書的話會附帶證書

(4)服務端收到加密過的隨機值並使用私鑰解密獲得第三個隨機值,這時候兩端都擁有了三個隨機值,可以通過這三個隨機值按照之前約定的加密方式生成密鑰,接下來的通信就可以通過該密鑰來加密解密

通過以上步驟可知,在 TLS 握手階段,兩端使用非對稱加密的方式來通信,但是因為非對稱加密損耗的性能比對稱加密大,所以在 正式傳輸數據 時,兩端使用 對稱加密 的方式通信。

PS:以上說明的都是 TLS 1.2 協議的握手情況 ,在 1.3 協議中,首次建立連接只需要一個 RTT,後面恢復連接不需要 RTT 了。

四、GET和POST的區別

從技術上說:

1、get請求能緩存,post不能;

2、post相對於get來說,安全一點點,因為get請求都會包含在URL里,會被瀏覽器保存歷史記錄,post不會,但是在抓包的情況是一樣的。

3、post可以request body來傳遞比get更多的數據,get米有這個技術。

4、url長度有限制,會影響get請求,長度限制是瀏覽器限制規定的,不是rfc(互聯網通信協議)規定的。

5、post支持更多的 編碼類型 且不對 數據類型 限制

③ 計網:運輸層

本篇文章先概括介紹運輸層協議的特點、進程之間的通信和埠等重要概念,然後講述比較簡單的UDP協議。然後討論較為復雜但非常重要的TCP協議和可靠傳輸的工作原理,包括停止等待協議和ARQ協議。在詳細講述TCP報文段的首部格式之後,討論TCP的三個重要問題:滑動窗口、流量控制和擁塞控制機制。最後,介紹TCP的連接管理。

從通信和信息處理的角度看,運輸層向它上面的應用層提供通信服務,它屬於面向通信部分的最高層,同時也是用戶功能中的最低層。

當網路的邊緣部分中的兩台主機使用網路 的核心部分的功能進行端到端的通信時,只有主機的協議棧才有運輸層,而網路核心部分中的路由器在轉發分組時都只用到下三層的功能。

運輸層有一個很重要的功能 復用和分用:

從IP層來說,通信的兩端是兩台主機。但實際上,真正進行通信的實體是 在主機中的進程,是這台主機中的一個進程和另一台主機中的一個進程在交換數據(即通信)。運輸層提供應用進程間的邏輯通信。「邏輯通信」的意思是:從應用層來看,只要把應用層報文交給下面的運輸層, 運輸層就可以把這報文傳送到對方的運輸層。但事實上這兩個運輸層之間並沒有一條水平方向的物理連接。數據的傳送是沿著圖中的虛線方向(經過多個層次)傳送的。

從這里可以看出網路層和運輸層有明顯的區別。網路層為主機之間提供邏輯通信,而運輸層為應用進程之間提供端到端的邏輯通信。

運輸層還要對收到的報文進行差錯檢測,而在網路層,IP數據報首部中的檢驗和欄位,只檢驗首部是否出現差錯而不檢查數據部分。

根據應用程序的不同需求,運輸層需要有兩種不同的運輸協議,即面向連接的TCP和無連接的UDP,這兩種協議就是本章要討論的主要內容。

當運輸層採用面向連接的TCP協議時,盡管下面的網路是不可靠的(只提供盡最大努力服務),但這種邏輯通信信道就相當於一條全雙工的可靠信道。但當運輸層釆用無連接的UDP協議時,這種邏輯通信信道仍然是一條不可靠信道。

TCP/IP運輸層的兩個主要協議都是互聯網的正式標准,即:

在TCP/IP體系中,則根據所使用的協議是TCP或 UDP,分別稱之為TCP報文段或UDP用戶數據報。

UDP在傳送數據之前不需要先建立連接。遠地主機的運輸層在收到UDP報文後,不需要給出任何確認。雖然UDP不提供可靠交付,但在某些情況下UDP卻是一種最有效的工作方式。

TCP則提供面向連接的服務。在傳送數據之前必須先建立連接,數據傳送結束後要釋放連接。TCP不提供廣播或多播服務。由於TCP要提供可靠的、面向連接的運輸服務,因此不可避免地增加了許多的開銷,佔用許多處理機資源。

前面己經提到過運輸層的復用和分用功能。應用層所有的應用進程都可以通過運輸層再傳送到IP層(網路層),這就是復用。運輸層從IP層收到發送給各應用進程的數據後,必須分別交付指明的各應用進程,這就是分用。顯然,給應用層的每個應用進程賦予一個非常明確的標志是至關重要的。

為了使運行不同操作系統的計算機的應用進程能夠互相通信,就必須用統一的方法(而這種方法必須與特定操作系統無關)對TCP/IP體系的應用進程進行標志。

解決這個問題的方法就是在運輸層使用協議埠號,或通常簡稱為埠。這就是說,雖然通信的終點是應用進程,但只要把所傳送的報文交到目的主機的某個合適的目的埠,剩下的工作(即最後交付目的進程)就由TCP或UDP來完成。

在協議棧層間的抽象的協議埠是軟體埠,和路由器或交換機上的硬體埠是完全不同的概念。軟體埠是應用層的各種協議進程與運輸實體進行層間交互的一種地址。

TCP/IP的運輸層用一個16位埠號來標志一個埠。但請注意,埠號只具有本地意義,它只是為了標志本計算機應用層中的各個進程在和運輸層交互時的層間介面。在互聯網不同計算機中,相同的埠號是沒有關聯的。

兩個計算機中的進程要互相通信,不僅必須知道對方的IP地址(為了找到對方的計算機),而且要知道對方的埠號(為了找到對方計算機中的應用進程)。

因此運輸層的埠號分為下面的兩大類:

用戶數據報協議UDP只在IP的數據報服務之上增加了很少一點的功能,這就是復用和分用的功能以及差錯檢測的功能。

UDP的主要特點是:

用戶數據報UDP有兩個欄位:數據欄位和首部欄位。首部欄位很簡單,只有8個位元組。由四個欄位組成,每個欄位的長度都是兩個位元組。各欄位意義如下:

當運輸層從IP層收到UDP數據報時,就根據首部中的目的埠,把UDP數據報通過相應的埠,上交最後的終點——應用進程。

如果接收方UDP發現收到的報文中的目的埠號不正確(即不存在對應於該埠號的應用進程),就丟棄該報文,並由網際控制報文協議ICMP發送「埠不可達」差錯報文給發送方。

UDP用戶數據報首部中檢驗和的計算方法有些特殊。在計算檢驗和時,要在UDP用戶 數據報之前增加12個位元組的偽首部。所謂「偽首部」是因為這種偽首部並不是UDP用戶數 據報真正的首部。只是在計算檢驗和時,臨時添加在UDP用戶數據報前面,得到一個臨時的 UDP用戶數據報。檢驗和就是按照這個臨時的UDP用戶數據報來計算的。偽首部既不向下傳
送也不向上遞交,而僅僅是為了計算檢驗和。

UDP計算檢驗和的方法和計算IP數據報首部檢驗和的方法相似。但不同的是:IP數據 報的檢驗和只檢驗IP數據報的首部,但UDP的檢驗和是把首部和數據部分一起都檢驗。

TCP是TCP/IP體系中非常復雜的一個協議,下面介紹TCP最主要的特點:

前面己經講過,每一條TCP連接有兩個端點,TCP連接的端點叫做套接字或插口。埠號拼接到IP地址即 構成了套接字。

因此,套接字的表示方法是在點分十進制的IP地址後面寫上埠號,中間用冒號或逗號隔開,例如說:

每一條TCP連接唯一地被通信兩端的兩個端點(即兩個套接字)所確定,例如:

這里IP1和IP2分別是兩個端點主機的IP地址,而port1和port2分別是兩個端點主機中的埠號。TCP連接的兩個套接字就是socket1和socket2。

總之,TCP連接就是由協議軟體所提供的一種抽象。

雖然有時為了方便,我們也可以說,在一個應用進程和另一個應用進程之間建立了一條TCP連接,但一定要記住:TCP連 接的端點是個很抽象的套接字,即(IP地址:埠號)。

我們知道,TCP發送的報文段是交給IP層傳送的。但IP層只能提供盡最大努力服務,也就是說,TCP下面的網路所提供的是不可靠的傳輸。因此,TCP必須釆用適當的措施才能使得兩個運輸層之間的通信變得可靠。

「停止等待」就是每發送完一個分組就停止發送,等待對方的確認。在收到確認後再發送下一個分組。

停止等待協議有以下四種情況:

停止等待協議的優點是簡單,但缺點是信道利用率太低。

信道利用率U可以用以下公式計算:

為了提高傳輸效率,發送方可以不使用低效率的停止等待協議,而是釆用流水線傳輸,這種傳輸方式可以獲得很高的信道利用率。

滑動窗口協議比較復雜,是TCP協議的精髓所在。這里先給出連續ARQ協議最基本的概念,但不涉及許多細節問題。

發送方維持的發送窗口,它的意義是:位於發送窗口內的分組都可連續發送出去,而不需要等待對方的確認。這樣,信道利用率就提高了。

連續ARQ協議規定,發送方每收到一個確認,就把發送窗口向前滑動一個分組的位置。

如果原來己經發送了前5個分組,那麼現在就可以發送窗口內的第6個分組了。

接收方一般都是釆用累積確認的方式。這就是說,接收方不必對收到的分組逐個發送 確認,而是在收到幾個分組後,對按序到達的最後一個分組發送確認,這就表示:到這個分組為止的所有分組都已正確收到了。

累積確認有優點也有缺點。優點是:容易實現,即使確認丟失也不必重傳。但缺點是不能向發送方反映出接收方己經正確收到的所有分組的信息。

如果發送方發送了前5個分組,而中間的第3個分組丟失了。這時接收方只能對前兩個分組發出確認。發送方無法知道後面三個分組的下落,而只好把後面的三個分組都再重傳一次。這就叫做Go-back-N(回退N)。

TCP雖然是面向位元組流的,但TCP傳送的數據單元卻是報文段。一個TCP報文段分為首部和數據兩部分,而TCP的全部功能都體現在它首部中各欄位的作用。

TCP報文段首部的前20個位元組是固定的,後面有4n位元組是根據需要而增加的選項。因此TCP首部的最小長度是20位元組。

首部固定部分各欄位的意義如下:

TCP的滑動窗口是以位元組為單位的。

現假定A收到了 B發來的確認報文段,其中窗口是20位元組,而確認號是31(這表明B期望收到的下一個序號是31,而序號30為止的數據已經收到了)。

A的發送窗口表示:在沒有收到B的確認的情況下,A可以連續把窗口內的數據都發送出去。凡是已經發送過的數據,在未收到確認之前都必須暫時保留,以便在超時重傳時使用。

發送窗口後沿的後面部分表示己發送且己收到了確認。發送窗口後沿的變化情況有兩種可能,即不動(沒有收到新的確認)和前移(收到了新的確認)。

發送窗口裡面的序號表示允許發送的序號。窗口越大,發送方就可以在收到對方確認之前連續發送更多的數據,因而可能獲得更高的傳輸效率。但A的發送窗口一定不能超過B的接收窗口數值。

發送窗口前沿的前面部分表示不允許發送的。發送窗口前沿通常是不斷向前移動,但也有可能不動。這對應於兩種情況:一是沒有收到新的確認,對方通知的窗口大小也不變;二是收到了 新的確認但對方通知的窗口縮小了,使得發送窗口前沿正好不動。

現在假定A發送了序號為31〜41的數據。這時,發送窗口位置並未改變, 但發送窗口內靠後面有11個位元組(灰色小方框表示)表示己發送但未收到確認。而發送窗口內靠前面的9個位元組(42〜50)是允許發送但尚未發送的。

從以上所述可以看出,要描述一個發送窗口的狀態需要三個指針:P1,P2和P3,小於P1的是已發送並已收到確認的部分,而大於P3的是不允許發送的部分:

再看一下B的接收窗口。B的接收窗口大小是20。在接收窗口外面,到30號為止的數據是已經發送過確認,並且已經交付主機了。因此在B可以不再保留這些數據。接收窗口內的序號(31〜50)是允許接收的。

此時B收到了序號為32和33的數據。這些數據沒有按序到達,因為序號為31的數據沒有收到(也許丟失了,也許滯留在網路中的某處)。請注意,B只能對按序收到的數據中的最高序號給出確認,因此B發送的確認報文段中的確認號仍然是31 (即期望收到的序號),而不能是32或33。

現在假定B收到了序號為31的數據,並把序號為31〜33的數據交付主機,然後B刪除這些數據。接著把接收窗口向前移動3個序號,同時給A發送確認,其中窗口值仍為20,但確認號是34。這表明B已經收到了到序號33為止的數據。我們注意到,B還收到了序號為37, 38和40的數據,但這些都沒有按序到達,只能先暫存在接收窗口中。

A在繼續發送完序號42〜53的數據後,指針P2向前移動和P3重合。發送窗口內的序號都已用完,但還沒有再收到確認(圖5-18)。由於A的發送窗口己滿,可用窗口已減小到零,因此必須停止發送。為了保證可靠傳輸,A只能認為B還沒有收到這些數據。於是,A在經過一段時間後(由超時計時器控制)就重傳這部分數據,重新設置超時計時器,直到收到B的確認為止。

CP的發送方在規定的時間內沒有收到確認就要重傳已發送的報文段。這種重傳的概念是很簡單的,但重傳時間的選擇卻是TCP最復雜的問題之一。

如果把超時重傳 時間設置得太短,就會引起很多報文段的不必要的重傳,使網路負荷增大。但若把超時重傳 時間設置得過長,則又使網路的空閑時間增大,降低了傳輸效率。

那麼,運輸層的超時計時器的超時重傳時間究竟應設置為多大呢?

TCP釆用了一種自適應演算法,它記錄一個報文段發出的時間,以及收到相應的確認的 時間。這兩個時間之差就是報文段的往返時間RTT。TCP保留了 RTT的一個加權平均往返時間RTT s

每當第一次測量到RTT樣本時,RTTs值就取為所測量到的RTT樣本 值。但以後每測量到一個新的RTT樣本,就按下式重新計算一次RTT s

顯然,超時計時器設置的超時重傳時間RTO應略大於上面得 出的加權平均往返時間RTT s ,所以RTO應該這樣計算。

而RTT D 是RTT的偏差的加權平均值,它與RTTs和新的RTT樣本之差有關。

現在發送出一個報文段,設定的重傳時間到了,還沒有收到確認。於是重傳報文段。經過了一段時間後,收到了確認報文段。現在的問題是:如何判定此確認報文段 是對先發送的報文段的確認,還是對後來重傳的報文段的確認?

Kam演算法進行修正。方法是:報文段每重傳一次,就把超時重傳時間RTO增大一些。典型的做法是取新的重傳時間為舊的重傳時間的2倍。當不再發生報文段的重傳時,才根據上面給出的式子計算超時重傳時間。

現在還有一個問題沒有討論。這就是若收到的報文段無差錯,只是未按序號,中間還缺少一些序號的數據,那麼能否設法只傳送缺少的數據而不重傳已經正確到達接收方的數據?答案是可以的。選擇確認就是一種可行的處理方法。

舉一個例子來說明選擇確認的工作原理。TCP的接收方在接收對方發送過來的數據位元組流的序號不連續,結果就形成了一些不連續的位元組塊。

可以看出,序號1〜1000收到了,但序號1001〜1500沒有收到。接下來的位元組流又收到了,可是又缺少了3001〜3500。再後面從序號4501起又沒有收到。

也就是說,接收方收到了和前面的位元組流不連續的兩個位元組塊。如果這些位元組的序號都在接收窗口之內,那麼接收方就先收下這些數據,但要把這些信息准確地告訴發送方,使發送方不要再重復發送這些已收到的數據。

一般說來,我們總是希望數據傳輸得更快一些。但如果發送方把數據發送得過快,接 收方就可能來不及接收,這就會造成數據的丟失。所謂流量控制就是讓發送方的發送速率不要太快,要讓接收方來得及接收。

利用滑動窗口機制可以很方便地在TCP連接上實現對發送方的流量控制。

設A向B發送數據。在連接建立時,B告訴了A:「我的接收窗口rwnd = 400」。因此,發送方的發送窗口不能超過接收方給出的接收窗口的數值。

我們應注意到,接收方的主機B進行了三次流量控制。第一次把窗口減小到rwnd = 300, 第二次又減到rwnd = 100,最後減到rwnd = 0,即不允許發送方再發送數據了。這種使發送方暫停發送的狀態將持續到主機B重新發出一個新的窗口值為止。

TCP協議使得在發送方不發送很小的報文段的同時,接收方也不要 在緩存剛剛有了一點小的空間就急忙把這個很小的窗口大小信息通知給發送方。

在計算機網路中的鏈路容量(即帶寬)、交換結點中的緩存和處理機等,都是網路的資源。在某段時間,若對網路中某一資源的需求超過了該資源所能提供的可用部分,網路的性能就要變壞。這種情況就叫做擁塞,即對資源需求之和 > 可用資源。

網路擁塞往往是由許多因素引起的。簡單地將處理機的速率提高或簡單地擴大緩存的存儲空間,可能會使上述情況緩解一些,但往往又會將瓶頸轉移到其他地方。問題的實質往往是整個系統的各個部分不匹配。只有所有的部分都平衡了,問題才會得到解決。

擁塞控制與流量控制的關系密切,它們之間也存在著一些差別。擁塞控制就是防止過多的數據注入到網路中,這樣可以使網路中的路由器或鏈路不致過載。流量控制往往是指點對點通信量的控制,是個端到端的問題(接收端控制發送端)。

下圖中橫坐標是提供的負載,代表單位時間內輸入給網路的分組數目。縱坐標是吞吐量,代表單位時間內從網路輸出的分組數目。

實踐證明,擁塞控制是很難設計的,因為它是一個動態的(而不是靜態的)問題。

從大的方面看,可以分為 開環控制 閉環控制 兩種方法:

TCP進行擁塞控制的演算法有四種,即慢開始、擁塞避免、快重傳和快恢復。

為了集中精力討論擁塞控制,我們假定:

擁塞控制也叫做基於窗口的擁塞控制。為此,發送方維持一個叫做擁塞窗口cwnd的狀態變數。擁塞窗口的大小取決於網路的擁塞程度,並且動態地在變化。發送方讓自己的發送窗口等於擁塞窗口。

發送方控制擁塞窗口的原則是:只要網路沒有出現擁塞,擁塞窗口就可以再增大一些,以便把更多的分組發送出去,這樣就可以提高網路的利用率。但只要網路出現擁塞或有可能出現擁塞,就必須把擁塞窗口減小一些,以減少注入到網路中的分組數,以便緩解網路出現的擁塞。

發送方又是如何知道網路發生了擁塞呢?我們知道,當網路發生擁塞時,路由器就要丟棄分組。因此只要發送方沒有按時收到應當到達的確認報文,也就是說,只要出現了超時,就可以猜想網路可能出現了擁塞。現在通信線路的傳輸質量一般都很好,因傳輸出差錯而丟棄分組的概率是很小的(遠小於1%)。因此,判斷網路擁塞的依據就是出現了超時。

慢開始演算法的思路是這樣的:當主機開始發送數據時,由於並不清楚網路的負荷情況,所以如果立即把大量數據位元組注入到網路,那麼就有可能引起網路發生擁塞。因此我們由小到大逐漸增大擁塞窗口數值。

新的RFC5681把初始擁塞窗口cwnd設置為不超過2至4個SMSS(發送方的最大報文段)的數值。慢開始規定,在每收到一個對新的報文段的確認後,可以把擁塞窗口增加最多一個SMSS的數值。

下面用例子說明慢開始演算法的原理。在一開始發送方先設置cwnd = 1,發送第一個報文段M1,接收方收到後確認M1。發送 方收到對M1的確認後,把cwnd從1增大到2,於是發送方接著發送M2和M3兩個報文 段。接收方收到後發回對M2和M3的確認。發送方每收到一個對新報文段的確認(重傳的不算在內)就使發送方的擁塞窗口加1,因此發送方在收到兩個確認後,cwnd就從2增大到4,並可發送M4〜M7共4個報文段。

與慢開始演算法相輔助的演算法是擁塞避免演算法。

擁塞避免演算法的思路是讓擁塞窗口 cwnd緩慢地增大,即每經過一個往返時間RTT就 把發送方的擁塞窗口cwnd加1,而不是像慢開始階段那樣加倍增長。在擁塞避免階段,擁塞窗口 cwnd按線性規律緩慢增長,比慢開始演算法的擁塞窗口增長速率緩慢得多。

為了防止擁塞窗口 cwnd增長過大引起網路擁塞,還需要設置一個慢開始門限ssthresh 狀態變數。慢開始門限ssthresh的用法如下:

下面用圖片說明慢開始演算法和擁塞避免演算法相互配合的原理。

其中ssthresh的初始值設置為16,開始時使用慢開始演算法,成指數性增長,當到達ssthresh值時,TCP協議預測可能會出現擁塞,所以開始使用避免擁塞演算法,成線性增長,當發生超時重傳時,立即減小擁塞窗口,重復上述步驟。

但是,有時,個別報文段會在網路中丟失,但實際上網路並未發生擁塞。如果發送方遲遲收 不到確認,就會產生超時,就會誤認為網路發生了擁塞。這就導致發送方錯誤地啟動慢開 始,把擁塞窗口cwnd又設置為1,因而降低了傳輸效率。

釆用快重傳演算法可以解決上述問題。快重傳演算法可以讓發送方盡早知道發生了個別報文段的丟失。快重傳演算法首先要求接收方不要等待自己發送數據時才進行捎帶確認,而是要立即發送確認,即使收到了失序的報文段也要立即發出對已收到的報文段的重復確認。

下面舉一個例子來說明快重傳演算法的原理。接收方收到了M1和M2後都分別及時發出了確認。現假定接收方沒有收到M3但卻收到了 M4。本來接收方可以什麼都不做。但按照快重傳演算法,接收方必須立即發送對M2的重復確認,以便讓發送方及 早知道接收方沒有收到報文段M3。發送方接著發送M5和M6。接收方收到後也仍要再次分別發出對M2的重復確認。這樣,發送方共收到了接收方的4個對M2的確認,其中後3個都是重復確認。快重傳演算法規定,發送方只要一連收到3個重復確認,就知道接收方確實沒 有收到報文段M3,因而應當立即進行重傳(即「快重傳」),這樣就不會出現超時,發送方也不就會誤認為出現了網路擁塞。

快恢復演算法與快重傳演算法配合使用,當使用快重傳演算法發現是由於數據丟失而引起的超時(不是網路擁塞引起的),就使用快恢復演算法,此時發送方調整門限值ssthresh=cwnd/2,同時設置擁塞窗口cwnd=ssthresh,並開始執行擁塞避免演算法。

慢開始、擁塞避免、快重傳和快恢復這四種演算法相輔相成,構成了TCP的擁塞控制。

網路層的策略對TCP擁塞控制影響最大的就是路由器的分組丟棄策略。在最簡單的情 況下,路由器的隊列通常都是按照「先進先出」的規則處理到來的分組。

由於隊列長度總是有限的,因此當隊列已滿時,以後再到達的所有分組(如果能夠繼續排隊,這些分組都將排在隊列的尾部)將都被丟棄。這就叫做尾部丟棄策略。

路由器的尾部丟棄往往會導致一連串分組的丟失,這就使發送方出現超時重傳,使 TCP進入擁塞控制的慢開始狀態,結果使TCP連接的發送方突然把數據的發送速率降低到 很小的數值。更為嚴重的是,在網路中通常有很多的TCP連接(它們有不同的源點和終 點),這些連接中的報文段通常是復用在網路層的IP數據報中傳送。在這種情況下,若發生了路由器中的尾部丟棄,就可能會同時影響到很多條TCP連接,結果使這許多TCP連接在同一時間突然都進入到慢開始狀態。這在TCP的術語中稱為全局同步。

為了避免發生網路中的全局同步現象,可以使用主動隊列管理AQM。

所謂「主動」就是不要等到路由器的隊列長度已經達到最大值時才不得不丟棄後面到達的分組。這樣就太被動了。應當在隊列長度達到某個值得警惕的數值時 (即當網路擁塞有了某些擁塞徵兆時),就主動丟棄到達的分組。這樣就提醒了發送方放慢發送的速率,因而有可能使網路擁塞的程度減輕,甚至不出現網路擁塞。

TCP是面向連接的協議。運輸連接是用來傳送TCP報文的。TCP運輸連接的建立和釋放是每一次面向連接的通信中必不可少的過程。因此,運輸連接就有三個階段,即:連接建立、數據傳送和連接釋放。運輸連接的管理就是使運輸連接的建立和釋放都能正常地進行。

在TCP連接建立過程中要解決以下三個問題:

TCP連接的建立釆用客戶伺服器方式。主動發起連接建立的應用進程叫做客戶,而被動等待連接建立的應用進程叫做伺服器。

TCP建立連接的過程叫做握手,握手需要在客戶和伺服器之間交換三個TCP報文段。

下面舉一個例子來說明TCP建立連接的過程。假定主機A運行的是TCP客戶程序,而B運行TCP伺服器程序。最初兩端的TCP進程都處於CLOSED(關閉)狀態。圖中在主機下面的方框分別是TCP進程所處的狀態。請注意,在本例中,A主動打開連接,而B被動打開連接。

一開始,B的TCP伺服器進程先創建傳輸控制塊TCB,准備接受客戶進程的連接請求。然後伺服器進

④ 什麼是RTT計算機網路里的東西

RTT(Round-Trip Time):往返時延。是指數據從網路一端傳到另一端所需的時間。通常,時延由發送時延、傳播時延、排隊時延、處理時延四個部分組成。

(1)發送時延

發送時延是結點將數據分組發送到傳輸媒介所需要的時間,也就是從分組的第一個比特開始發送算起,到最後一個比特發送完畢所需要的時間。顯然,發送時延與網路介面/信道的傳輸速率成反比,與數據分組的長度成正比。

(2)傳播時延

傳播時延是電磁波在信道中傳播一定距離所需要花費的時間,傳播時延和信道的傳輸速率無關,
而是取決於傳輸媒介的長度,以及某種物理形式的信號在傳輸媒介中的傳播速度。

如電磁波在自由空間的傳播速度是光速,即3×105km/s。電磁波在網路傳輸媒體中的傳播速度比在自由空間中的傳播速度要略低一些,在銅線中的傳播速度約為2.3×105km/s
,在光纖中的傳播速度約為2.0×105km/s 。

(3)排隊時延

排隊時延是分組在所經過的網路結點的緩存隊列中排隊所經歷的時延,排隊時延的長短主要取決於網路中當時的通信量,當網路的通信流量大時,排隊時雀畢間就長,極端情況下,當網路發生擁塞導致分組丟失時,該結點的排隊時延視為無窮大。

此外,在有優先順序演算法的網路中,排隊時延還取決於數據的優先順序和結點的隊列調度演算法。

(4)處理時延

處理時延是分組在中間結點的存儲轉發過程中而進行的一些必要的處理所花費的時間,這些處理包括提取分組的首部,進行差錯校驗,為分組定址和選路等。

(4)計算機網路應用層rtt擴展閱讀

網路源銷端到端的時延是幾種時延的總合,其計算公式是:

總時延=傳播時延+發送時延+排隊時延+處理時延

根據網路的不同情況,有時有些時延可以忽略不計,如在區域網中,傳播時延很小可以忽略不計;當網路沒有擁塞時,分組在各個結點的排隊時延可以忽略不計。

往返時延(Round-Trip Time,RTT)也是一個重要的性能指標,它表示從發送方發送數據開始,到發送方收到來自接收方的確認,總共經歷的時延。對於復雹歲游雜的網路,往返時延要包括各中間結點的處理時延和轉發數據時的發送時延。

⑤ 計算機網路的應用層協議主要有哪些

應用層協議包含以下內容:

1、DNS:域名系統DNS是網際網路使用的命名系統,用來把便於人們使用的機器名字轉換為IP地址。

2、FTP:文件傳輸協議FTP是網際網路上使用得最廣泛的文件傳送協議。FTP提供互動式的訪問,允許客戶指明文件類型與格式鎮橋,並允許文件具有存取許可權。FTP其於TCP。

3、telnet遠程終端協議御亂猛:telnet是一個簡單的遠程終端協議,它也是網際網路的正式標准。又稱為終端模擬協議。

4、HTTP:超文本傳送協議,是面向事務的應用層協議,它是萬維網上能夠可靠地交換文件的重要基礎。http使用面向連接的TCP作為運輸層協議,保證了數據的可靠傳輸。

5、電子郵件協議SMTP:即簡單郵件傳送協議。SMTP規定了在兩個相互通信的SMTP進程之間應如何交換信息。SMTP通信的三個陪旁階段:建立連接、郵件傳送、連接釋放。

6、POP3:郵件讀取協議,POP3(Post Office Protocol 3)協議通常被用來接收電子郵件。

7、遠程登錄協議(Telnet):用於實現遠程登錄功能。

8、SNMP:簡單網路管理協議。由三部分組成:SNMP本身、管理信息結構SMI和管理信息MIB。SNMP定義了管理站和代理之間所交換的分組格式。SMI定義了命名對象類型的通用規則,以及把對象和對象的值進行編碼。MIB在被管理的實體中創建了命名對象,並規定類型。

⑥ 網路中的RTT是什麼意思

RTT(Round-Trip Time): 往返時延。在計算機網路中它是一個重要的性能指標,表示從發送端發送數據開始,到發送端收到來自接收端的確認(接收端收到數據後便立即發送確認),總共經歷的時延。 RTT(Radio Transmission Technology): 無線傳輸技術。參考CDMA2000詞條中的CDMA2000 1xRTT。 RTT(Radiation Tracking Transcer): 紅外線跟蹤系統, 輻射跟蹤換能器。 RTT(Radio Teletype (-writer)): 無線電電傳打字電報機。 RTT(Radioteletype Transmitter): 無線電電傳打字電報發射機。 RTT(Real-Time Tactics):即時戰術游戲又稱「實時戰術」游戲。它與即時戰略(RTS:Real-Time Strategy)相類似,但缺少必要的戰略要素,如資源採集、建造、發展等。一種常見的誤解是認為「只要是即時進行的戰爭游戲就是即時戰略游戲」。其實即時戰略游戲的定義是很嚴格的,即時戰略的「戰略(Strategy)」的謀定過程必須是即時的,如果只有戰斗是即時的,而採集、建造、發展等戰略元素卻以回合制進行,則該游戲不能歸為即時戰略游戲。如果該游戲完全沒有上述戰略元素,則只能歸為即時戰術(RTT:Real-Time Tactics)游戲。

⑦ [計算機網路之六] 傳輸層

  傳輸層向它上面的應用層提供通信服務,它屬於面向通信部分的最高層,同時也是用戶功能中的最底層。

  從傳輸層的角度,通信的真正端點並不是主機而是主機中的進程。

  傳輸層有 分用 復用 的功能。 「復用」 是指在發送方不同的應用進程都可以使用同一個運輸層協議傳送數據, 「分用」 是指接收方的運輸層在剝去報文的首部後能夠把這些數據正確交付目的應用進程。

  網路層和運輸層有明顯的區別,網路層為主機之間提供邏輯通信,而運輸層為應用進程之間提供端到端的邏輯通信。

知名埠號 :0~1023
登記埠號 :1024~49151
客戶端短暫埠號 :49152~65535


① 無連接。 發送數據之前不需要建立連接,因此減少了開銷和發送數據之前的時延。
② 盡最大努力交付。 即不保證可靠交付,因此主機不需要維持復雜的連接狀態表。
③ 面向報文的。 對應用層交下來的報文,既不合並,也不拆分,而是保留這些報文的邊界,UDP 一次交付一個完整的報文。

  用戶數據報 UDP 有兩個欄位:數據欄位和首部欄位。首部欄位很簡單,只有 8 個位元組,由四個欄位組成,每個欄位的長度都是兩個位元組。各欄位意義如下:

① 源埠 在需要對方回信時選用。不需要時可用全0。
② 目的埠 目的埠號。這在終點交付報文時必須使用。
③ 長度 用戶數據報的長度,最小值為 8 (僅有首部)。
④ 檢驗和 檢測用戶數據報在傳輸中是否有錯。有錯就丟棄。

  用戶數據報首部檢驗和的計算和校驗都要計算出一個偽首部。


① 面向連接。

  應用程序在使用 TCP 協議之前,必須先建立 TCP 連接;傳送數據完畢後,必須釋放已經建立的 TCP 連接。類似於打電話:通話前要先撥號建立連接,通話結束後要掛機釋放連接。

② 一對一。

  TCP 連接只能是點對點的(一對一)。

③ 可靠交付。

  通過 TCP 連接傳送的數據,無差錯、不丟失、不重復,並且按序到達。

④ 全雙工通信。

  通信雙方的應用進程在任何時候都能發送和接收數據,TCP 連接的兩端都設有發送緩存和接收緩存,用來臨時存放雙向通信的數據。

⑤ 面向位元組流。

  TCP 中的 「流」 指的是流入到進程或從進程流出的位元組序列。

  「面向位元組流」 的含義:雖然應用程序和 TCP 的互動式一次一個數據塊(大小不等),但 TCP 把應用程序交下來的數據僅僅看成是一連串無結構的位元組流。TCP 並不知道所傳送的位元組流的含義。TCP 不保證接收方應用程序鎖收到的數據塊和發送方應用程序所發出的數據塊具有對應的大小關系。但接收方應用程序收到的位元組流必須和發送方應用程序發出的位元組流完全一樣,當然接收方的應用程序必須有能力識別收到的位元組流,把它還原成有意義的應用層數據。

  TCP 連接是協議軟體提供的一種抽象,每一條 TCP 連接唯一地被通信兩端的兩個端點(即兩個套接字)所確定,即:

  TCP 連接 ::= {socket1, socket2} = {(IP1: port1), (IP2: port2)}

  IP1 和 IP2 分別是兩個端點主機的 IP 地址,port1 和 port2 分別是兩端端點主機中的埠號。


  網路只能提供最大努力的服務,是不可靠的,因此 TCP 必須採用適當的措施才能使得兩個運輸層之間的通信變得可靠。當出現差錯時讓發送方重傳出現差錯的數據,同時在接收方來不及處理收到的數據時,及時告知發送方適當降低發送數據的速度,這樣就可以在不可靠的傳輸信道實現可靠傳輸。

  ARQ(Auto Repeat-reQuest):自動重傳請求。

  發送方每發送完一個分組就停止發送,等待接收方確認,在收到確認後再發送下一個分組。
  A 是發送方,B 是接收方。

  A 每發送一個分組後,等待 B 對該分組的確認後,再接著發送下一個分組。

【發送方】A 發送的分組在傳輸過程中出錯,可能是丟失了,也可能是分組受到干擾出錯了
【接收方】這時 B 直接丟棄分組,什麼也不做(也不通知 A 受到的分組有差錯)。

【解決方案】發送方在每發送完一個分組時設置一個 超時計數器 ,只要超過一段時間仍然沒有接收到確認,就認為剛才發送的分組丟失了,因而重傳前面發送過的分組,這叫 超時重傳 。反之在超時計時器到期之前收到了相應的確認,就撤銷該超時計時器。

第一,A 在發送完一個分組後, 必須暫時保留已發送的分組的副本 (在發生超時重傳時使用)。只有在收到相應的確認後才能清楚暫時保留的分組副本。

第二,分組和確認分組都必須進行 編號 。這樣才能明確是哪一個發送出去的分組受到了確認,而哪一個分組還沒有收到確認。

第三,超時計時器設置的 重傳時間應當比數據在分組傳輸的平均往返時間更長一些

【發送方】超時重傳時間內沒有收到確認報文,無法確認是發送出錯、丟失,還是接收方的確認丟失,超時計時器到期後就要重傳。
【接收方】丟棄收到的重復分組,不向上層交付;向發送方發送確認。

【發送方】收下遲到的確認,並且丟棄

  發送方大部分時間都在等待確認,信道的利用率低

  使用流水線的 ARQ 可以提高信道利用率

【發送方】維持一個發送窗口,位於發送窗口內的分組都可連續發送出去,而不需要等待對方的確認。

回退N幀協議 :如果發送方發送了多個分組,但中間的某個分組丟失了,這時接收方只能對丟失分組之前的分組發出確認,而發送方無法知道丟失分組及後面分組的接收情況,只好把丟失分組及後面的分組重傳一次,這叫 Go-back-N ,表示需要再退回來重傳已發送過的 N 個分組。


  前面 20 個位元組固定,因此 TCP 首部最小長度是 20 位元組。

  TCP 的滑動窗口以位元組為單位,窗口後沿的部分表示已發送且已收到通知,窗口裡的序號表示允許發送的序號,窗口前沿之前的數據暫時不允許發送,需要等待收到接收方的確認後前沿往前移才可發送。

描述一個發送窗口需要三個指針:P1、P2 和 P3,如圖所示:

  小於 P1 的是已發送並已收到確認的部分,而大於 P3 的是不允許發送的部分。

  P3 - P1 = A 的發送窗口

  P2 - P1 = 已發送但尚未收到確認的位元組數

  P3 - P2 = 允許發送但當前尚未發送的位元組數(又稱為 可用窗口 有效窗口

  接收方 B 接收窗口大小為20,因為未收到 31 的數據,即使已收到後面的序號 32、33 的數據,返回的確認號仍然是 31。

  現在接收方收到了 31、32、33,並返回確認號 33,接收窗口往前滑動 3 個序號,發送方接收到確認,發送窗口也向前滑動 3 個序號大小,現在 A 可以發送序號 51~53 的數據了。

  當發送方將發送窗口內的數據都發送出去,但是接收方的確認可能由於網路擁塞滯留,這時發送方發送窗口已滿,可用窗口為 0,只能等待接收方的確認報文到達。

  TCP 為了保證可靠傳輸,要求必須受到對已發送報文的確認,如果超過一定時間未受到確認報文,則重傳已發送的報文。這個時間就叫 超時重傳時間 ,很明顯超時重傳時間的大小設置應該更貼近網路的實際情況,如果網路狀況好,就設短一點,否則使網路的空閑時間增大,降低了傳輸效率;網路差就設長一點,否則會引起很多不必要的重傳,使網路負荷增大。

  TCP 採用了一種自適應的演算法:

  RTT(報文段的往返時間)、RTTs(加權平均往返時間),RTTs 的計算公式:

RTTd(RTT 的偏差的加權平均值)、RTO(RetransmissionTime-Out 超時重傳時間):

【場景】TCP 的接收方在接收對方發送過來的數據位元組流的序號不連續,形成一些不連續的位元組塊,如果簡單按照回退N幀協議處理,意味著要重傳第一個未收到的序號數據塊及之後的數據,如果能通知發送方已收到了哪些數據(選擇確認),就可以讓發送方只發送接收方未收到的數據。



  流量控制就是讓發送方的發送速率不要太快,要讓接收方來得及接收。

  當發送方收到接收方通知,將窗口縮小為 0 時,發送方將暫時不能發送數據了,必須等接收方通知更新接收窗口大小,但是這個通知又有可能丟失,導致發送方沒收到通知。

  為了避免雙方互相等待死鎖,TCP 為每個鏈接設有一個 持續計時器 ,只要 TCP 連接的一方收到對方的零窗口通知,就啟動持續計時器。若持續計時器設置的時間到期,就發送一個零窗口 探測報文段 (僅攜帶 1 位元組的數據),而對方就在確認這個探測報文段時給出了現在的窗口值。如果窗口仍然是零,那麼受到這個報文段的一方就重新設置持續計時器;如果窗口不是零,那麼死鎖的僵局就可以打破了。



【優點】提高網路利用率
【缺點】可能會發生某種程度的延遲

【場景】接收數據的主機如果每次都立刻回復確認應答的話,可能會返回一個較小的窗口,因為接收方剛接收完數,緩沖區已滿。

【糊塗窗口綜合征問題】
TCP 接收方緩存已滿,而互動式的應用進程一次只從接收緩存中讀取 1 個位元組(這樣就使接收緩存空間僅騰出 1 個位元組),然後向發送方發送確認,並把窗口設置為 1 個位元組(但發送的數據報是 40 位元組長,TCP 首部 + IP 數據報首部)。接著,發送方又發來 1 個位元組的數據(注意發送方發送的 IP 數據報是 41 位元組長)。接收方發回確認,仍然將窗口設置為 1 個位元組。這樣進行下去,使網路的效率很低。

  TCP 文件傳輸中,就採用了兩個數據段返回一次確認應答,並且等待一定時間後沒有其他數據包到達時也依然發送確認應答。

  當對網路中某一資源的需求超過了該資源所能提供的可用部分,網路的性能就要變壞,這種情況就叫做 擁塞



  慢開始(slow-start)、擁塞避免(congestion avoidance)、快重傳(fast retransmit)和快恢復(fast recovery)。

【演算法思路】

  當主機開始發送數據時,由於並不清楚網路的負荷情況,所以如果立即把大量數據位元組注入網路,那麼就有可能引起網路發生擁塞。較好的方法是先探測一下,即 由小到大逐漸增大發送窗口 ,也就是說, 由小到大逐漸增大擁塞窗口數值

【處理過程】

   慢開始門限值 ssthresh 決定了擁塞窗口達到多大時要執行什麼演算法。

① 當 cwnd < ssthresh 時,使用慢開始演算法;
② 當 cwnd > ssthresh 時,停止使用慢開始演算法而改用擁塞避免演算法;
③ 當 cwnd = ssthresh 時,既可使用慢開始演算法,也可使用擁塞避免演算法。

  在擁塞窗口 cwnd 達到門限值之前,發送方每一輪次收到確認應答後,cwnd 就增大為原來的兩倍;達到門限值後,執行擁塞避免演算法。

PS. 慢開始只是表示初始發送數據少,不代表發送速率增長速度慢,實際上是指數級增長非常快。

【演算法思路】

  讓擁塞窗口 cwnd 緩慢地增大,即每經過一個往返時間 RTT 就把發送方的擁塞窗口 cwnd 加 1,而不是像慢開始階段那樣加倍增長。擁塞避免階段有 「加法增大」 的特點,按線性規律緩慢增長,使網路比較不容易出現擁塞

【處理過程】

  在執行擁塞避免演算法階段,當網路出現超時時,發送方判斷為網路擁塞,調整門限值為當前擁塞窗口的一半,即 ssthresh = cwnd / 2,同時擁塞窗口重置為 1,即 cwnd = 1,進入慢開始階段。

【演算法原理】

① 快重傳

【場景】有時,個別報文段會在網路中丟失,但實際上網路並未發生擁塞。如果發送方遲遲收不到確認,就會產生超時,就會誤認為網路發生了擁塞,導致發送方錯誤地啟動慢開始,把擁塞窗口 cwnd 又設置為 1,因而降低了傳輸效率。

【方案】接收方不要等待自己發送數據時才進行捎帶確認,而是要立即發送確認,即使收到了失序的報文段也要立即發出對已收到的報文段的重復確認,當發送方 一連收到 3 個重復確認 ,就知道接收方確實沒有收到某個報文段,因而應當 立即進行重傳

② 快恢復:

  發送方知道只是丟失了個別的報文段,於是不啟動慢開始,而是執行快恢復演算法,調整發送方門限值 ssthresh = cwnd / 2,同時設置擁塞窗口 cwnd = ssthresh = 8,並開始執行擁塞避免演算法。


擁塞控制的流程如下:

  擁塞窗口 cwnd,接收方窗口 rwnd, 發送方發送窗口的上限值 = Min[rwnd, cwnd]

① 當 rwnd < cwnd,接收方的接收能力限制發送方窗口大小;
② 當 cwnd < rwnd,網路的擁塞程度限制發送方窗口大小。


【問題背景】

  路由器採取分組丟棄策略,即按照 先進先出(FIFO) 規則處理分組,當隊列已滿時,則丟棄後面到達的分組,這叫 尾部丟棄策略

  丟失的分組會導致發送方出現超時重傳,發送方轉而執行慢開始演算法,不同分組屬於不同 TCP 連接,導致很多 TCP 同時進入慢開始狀態,這種現象稱為 全局同步

【解決方案】

  主動隊列管理 AQM:不等到路由器的隊列長度已經達到最大值時才不得不丟棄後面到達的分組,而是在隊列長度達到某個警惕值時就主動丟棄到達的分組,這樣就提醒了發送方放慢發送的速率,因而有可能使網路擁塞的程度減輕,甚至不出現網路擁塞。


  TCP 是面向連接的協議,運輸連接有三個階段: 連接建立、數據傳送、連接釋放

  TCP 連接建立過程要解決的幾個問題:

① 使每一方能夠確知對方的存在;
② 允許雙方協商一些參數(如最大窗口值、是否使用窗口擴大選項和時間戳選項以及服務質量等);
③ 能夠對運輸實體資源(如緩存大小、連接表中的項目等)進行分配。

  TCP 建立連接的過程叫做握手,握手需要在客戶和伺服器之間交換三個 TCP 報文段,即 三次握手

  最初客戶端和服務端都處於 CLOSED(關閉) 狀態,A(Client)主動打開連接,B(Server)被動打開連接。

  一開始,B 的 TCP 伺服器進程先創建 傳輸控制塊 TCB ,准備接受客戶進程的連接請求。然後伺服器進程就處於 LISTEN(收聽)狀態,等待客戶端的連接請求。如有,即作出響應。

   第一次握手 :A 的 TCP 客戶進程也是首先創建傳輸控制塊 TCB,准備接受客戶進程的連接請求。然後在打算建立 TCP 連接時,向 B 發出連接請求報文段,這時首部中的同步位 SYN = 1,同時選擇一個初始序號 seq = x。TCP 規定,SYN 報文段(即 SYN = 1 的報文段)不能攜帶數據,但要 消耗掉一個序號 。這時,TCP 客戶進程進入 SYN-SENT(同步已發送) 狀態。

   第二次握手 :B 收到連接請求報文段後,如同意建立連接,則向 A 發送確認。在確認報文段中應把 SYN 位和 ACK 位都置 1,確認號是 ack = x + 1,同時也為自己選擇一個初始序號 seq = y。請注意,這個報文段也不能攜帶數據,但同樣 要消耗掉一個序號 。這時 TCP 伺服器進程進入 SYN-RCVD(同步收到) 狀態。

   第三次握手 :TCP 客戶進程收到 B 的確認後,還要向 B 給出確認。確認報文段的 ACK 置 1,確認號 ack = y + 1,而自己的序號 seq = x + 1。TCP 的標准規定,ACK 報文段可以攜帶數據。但 如果不攜帶數據則不消耗序號 ,在這種情況下,下一個數據報文段的序號仍是 seq = x + 1。這時,TCP 連接已經建立,A 進入 ESTABLISHED(已建立連接) 狀態。當 B 收到 A 的確認後,也進入 ESTABLISHED(已建立連接)狀態。








  數據傳輸結束後,通信的方法都可釋放連接。現在 A 和 B 都處於 ESTABLISHED 狀態。

   第一次揮手 :A 的應用進程先向其 TCP 發出連接釋放報文段,並停止再發送數據,主動關閉 TCP 連接。A 把連接釋放報文段首部的終止控制位 FIN 置 1,其序號 seq = u,它等於前面已傳送過的數據的最後一個位元組的序號加 1。這時 A 進入 FIN-WAIT-1(終止等待 1)狀態,等待 B 的確認。請注意,TCP 規定,FIN 報文段即使不攜帶數據,它也消耗掉一個序號。

   第二次揮手 :B 收到連接釋放報文後即發出確認,確認號是 ack = u + 1,而這個報文段自己的序號是 v,等於 B 前面已傳送過的最後一個位元組的序號加 1。然後 B 就進入 CLOSE-WAIT(關閉等待)狀態。TCP 伺服器進程這時應通知高層應用程序,因而從 A 到 B 這個方向的連接就釋放了,這時的 TCP 連接處於半關閉(half-close)狀態,即 A 已經沒有數據要發送了,但 B 若發送數,A 仍要接收。也就是說,從 B 到 A 這個方向的連接並未關閉,這個狀態可能會持續一段時間。A 收到來自 B 的確認後,就進入 FIN-WAIT-2(終止等待 2)狀態,等待 B 發出的連接釋放報文段。

   第三次揮手 :若 B 已經沒有要向 A 發送的數據,其應用進程就通知 TCP 釋放連接。這時 B 發出的連接釋放報文段必須使 FIN = 1。現假定 B 的序號為 w(在半關閉狀態 B 可能又發送了一些數據)。B 還必須重復上次已發送過的確認號 ack = u + 1。這時 B 就進入 LAST-ACK(最後確認)狀態,等待 A 的確認。

   第四次揮手 :A 在收到 B 的連接釋放報文段後,必須對此發出確認。在確認報文段中把 ACK 置 1,確認號 ack = w + 1,而自己的序號是 seq = u + 1(根據 TCP 標准,前面發送過的 FIN 報文段要消耗一個序號)。然後進入 TIME-WAIT(時間等待)狀態。請注意,現在 TCP 連接還沒有釋放掉。必須經過時間等待計時器(TIME-WAIT timer)設置的時間 2MSL 後,A 才進入到 CLOSED 狀態,然後撤銷傳輸控制塊,結束這次 TCP 連接。當然如果 B 一收到 A 的確認就進入 CLOSED 狀態,然後撤銷傳輸控制塊。所以在釋放連接時,B 結束 TCP 連接的時間要早於 A。




⑧ 計算機網路——應用層-Web&HTTP

計算機網路系列博文——目錄

20世紀90年代初
網際網路應用

Web應用的組成

由對象組成。對象是一個文件,如HTML文件,JPEG圖像,Java程序,視頻片段等。
對象可通過一個URL地址定址。
Web頁面常由一個HTML基本文件和多個引用對象構成。

URL(Uniform Resoure Locator):統一資源定位器 RFC1738

用以定址Web對象
由一個存放對象的伺服器主機名和對象路徑名構成。

HTTP 由客戶端程序和服務端程序實現,二者通過交換HTTP報文會話。
HTTP規范定義了HTTP客戶端和服務端之間的通信協議。

Web瀏覽器實現HTTP客戶端,請求、接收、展示Web對象
Web伺服器實現HTTP服務端,響應客戶的請求,發送對象

HTTP使用TCP作為支撐運輸層協議。

埠:80

無狀態協議 伺服器不保存關於客戶的任何信息
伺服器向客戶發送被請求的文件,而不存儲任何關於客戶的狀態信息。

往返時間(Round-Trip Time,RTT)
一個短分組從客戶到伺服器然後再返回客戶所花費的時間。

某客戶和伺服器的一次會話中,每個請求/響應對通過一個單獨的TCP連接傳輸

HTTP 1.0版本使用非持續性連接

對多個待獲得的web對象,客戶端一次只請求一個對象,待前一個對象接收完畢後再發送對下一個對象的請求。

時間分析

瀏覽器通常支持並行的TCP連接。並行TCP連接數通常為5~10個。
對多個待獲得的web對象,客戶端一次可同時建立多個TCP連接,以同時請求多個web對象。
時間分析

某客戶和伺服器的一次會話中,所有請求/響應對經同一TCP連接傳輸

HTTP 1.1版本在默認方式下採用持續連接,但也可由客戶端/伺服器配置為非持續連接。

客戶端只有收到前一個響應後才發送新的請求
可理解為同個TCP內的串列

時間分析

客戶端只要遇到一個引用對象就盡快發出請求
可理解為同個TCP內的並行
HTTP 1.1的默認選項

時間分析

TCP 三次握手
1.客戶向伺服器發送一個小TCP報文段;
2.伺服器用一個小TCP報文段做出確認和響應;
3.客戶向伺服器返回確認和一個HTTP請求報文;
4.伺服器返回相應HTML文件;

HTTP規范
RFC 1945 , RFC 2616

用ASCII文本書寫
HTTP協議有兩類消息,請求消息(request)和響應消息(response)

請求行 HTTP請求報文的第一行

方法

首部行 請求行後繼的其它行,包含一些會話信息

空行 回車換行,分隔首部行和實體體

實體體(entity body)
GET方法下實體體為空
POST方法下實體體包含表單信息

狀態行

常見狀態碼

首部行

空行

實體體
包含了所請求的對象

HTTP是無狀態協議,但cookie技術允許伺服器識別用戶
cookie在無狀態的HTTP之上建立一個用戶會話層

參見 [RFC 6265]

cookie組件

cookie技術的爭議在於它可能泄露用戶的隱私

代表原Web伺服器來響應HTTP請求的網路實體

Web緩沖器通常由ISP購買並安裝

允許緩存器證實其緩存的副本是新的。
如果緩存器有web對象最新的版本,則初始伺服器不需要向緩存器發送該web對象

在HTTP請求消息中聲明所持有版本的日期
If-modified-since: <date>

如果緩存的版本是最新的,則響應消息中不包含對象
HTTP/1.0 304 Not Modified

內容分發網路(Content Distribution Network,CDN)
基於緩存器技術,CDN公司在網際網路上安裝許多地理上分散的緩存器,使得大流量本地化。
有共享CDN(Akamai,Limelight),專用CDN(谷歌,微軟)

⑨ RTT全稱源自哪

。普通的圖形渲染流程中,最終結果是渲染到幀緩存中,最後顯示到屏幕上,然後可以把紋理繼續應用到場景繪制中,比如渲染一個場景A到紋理中,在另一個場景B的一個電視屏幕上把剛才的紋理貼上去,就像是在播放A一樣,再比如各種鏡子中的景象也是一樣道理,陰影圖(shadow mapping)

⑩ 計算機網路體系分為哪四層

1.、應用層

應用層對應於OSI參考模型的高層,為用戶提供所需要的各種服務,例如:FTP、Telnet、DNS、SMTP等.

2.、傳輸層

傳輸層對應於OSI參考模型的傳輸層,為應用灶拍游層實體提供端到端的通信功能,保證了數據包的順序傳送及數據的完整性。該層定義了兩個主要的協議:傳輸控制協議(TCP)和用戶數據報協議(UDP).

TCP協議提供的是一種可靠的、通過「三次握手」來連接的數據傳輸服務;而UDP協議提供的則是不保證可靠的(並不是不可靠)、無連接的數據傳輸服務.

3.、網際互聯層

網際互聯層對應於OSI參考模型的網路層,主要解決主機到主機的通信問題。它所包含的協議設計數據包在整個網路上的邏輯傳輸。注重重新賦予主機一個IP地址來完成對主機的定址,它還負責數據包在多種網路中的路由。

該層有三個主要協議:網際協議(IP)、互聯網組管理協議(IGMP)和互聯網控制報文賀嘩協議(ICMP)。

IP協議是網際互聯層最重要的協議,它提供的是一個可靠、無連接的數據報傳遞服務。

4.、網路接入層(即主機-網路層)

網路接入層與OSI參考模型中的物理層和數據鏈路層相對應。它負責監視數據在主機和網路之間的交換。事實上,TCP/IP本身並未定義該層的協議,而由參與互連的各網路使用自己的物理層和數據鏈路層協議,然後與TCP/IP的網路接入層進行連接。地址解析協議(ARP)工作在此層,即OSI參考模型的數據鏈路層。

(10)計算機網路應用層rtt擴展閱讀:

OSI將計算機網路體系結構(architecture)劃分為以下七層:

物理層: 將數據轉換為可通過物理介質傳送的電子信號相當於郵局中的搬運工人。

數據鏈路層: 決定訪問網路介質的方式。

在此層將數據分幀,並處理流控制。本層指定拓撲結構並提供硬體定址,相當於郵局中的裝拆箱工人。

網路層: 使用權數據路由經過大型網路 相當於郵局中的排序工人。

傳輸層: 提供終端到終端的可靠連接 相當於公司中跑郵局的送信職員。

會話層: 允許用戶使用簡單易記的名稱建立連接 相當於公司中收寄信、寫信封與拆信封的秘書。

表示層: 協商數據交換格式 相當公司中簡報老闆、替老闆寫信的助理。

應用層: 用戶的應用程序和網路之間的介面老闆。