文章很長,建議收藏起來,慢慢讀! 瘋狂創客圈爲小夥伴奉上如下珍貴的學習資源:html
高併發 必讀 的精彩博文 | |
---|---|
nacos 實戰(史上最全) | sentinel (史上最全+入門教程) |
Zookeeper 分佈式鎖 (圖解+秒懂+史上最全) | Webflux(史上最全) |
SpringCloud gateway (史上最全) | TCP/IP(圖解+秒懂+史上最全) |
10分鐘看懂, Java NIO 底層原理 | Feign原理 (圖解) |
更多精彩博文 ..... | 請參見【 瘋狂創客圈 高併發 總目錄 】 |
(1)、解析域名。java
(2)、發起TCP的3次握手。react
(3)、創建TCP請求後發起HTTP請求。程序員
(4)、服務器相應HTTP請求。web
(5)、瀏覽器獲得HTML代碼,進行解析和處理JSON數據,並請求HTML代碼中的靜態資源(JS、CSS、圖片等)。面試
(6)、瀏覽器對頁面進行渲染。算法
★ GET:獲取資源。sql
★ POST:表單提交。編程
★ HEAD:獲取報頭信息,HEAD 方法與 GET 方法相似,但並不會返回響應主體。設計模式
★ PUT 與PATCH:更新資源,PUT 對後臺來講 PUT 方法的參數是一個完整的資源對象,它包含了對象的全部字段,PATCH 對後臺來講 PATCH 方法的參數只包含咱們須要修改的資源對象的字段。
★ DELETE:刪除資源。
★ OPTIONS:獲取目標資源所支持的通訊選項,使用 OPTIONS 方法對服務器發起請求,以檢測服務器支持哪些 HTTP 方法。
加密方式: 1)、對稱密碼算法:指加密和解密使用相同的密鑰,速度高,可加密內容較大,用來加密會話過程當中的消息。典型算法DES、AES、RC五、IDEA(分組加密)RC4。
2)、非對稱密碼算法:又稱爲公鑰加密算法,是指加密和解密使用不一樣的密鑰,加密速度較慢,但能提供更好的身份認證技術,用來加密對稱加密的密鑰(公開的密鑰用於加密,私有的密鑰用於解密)典型的算法RSA、DSA、DH。
3)、散列算法:將文件內容經過此算法加密變成固定長度的值(散列值),這個過程可使用密鑰也能夠不使用。這種散列變化是不可逆的,也就是說不能從散列值編程原文,所以散列變化通道經常使用語驗證原文是否被篡改。典型的算法MD五、SHA、BASE6四、CRC等。
HTTP 的URL 以http:// 開頭,而HTTPS 的URL 以https:// 開頭
HTTP 是不安全的,而 HTTPS 是安全的
HTTP 標準端口是80 ,而 HTTPS 的標準端口是443
在OSI 網絡模型中,HTTP工做於應用層,而HTTPS 的安全傳輸機制工做在傳輸層
HTTP 沒法加密,而HTTPS 對傳輸的數據進行加密
HTTP無需證書,而HTTPS 須要CA機構頒發的SSL證書
無狀態協議對於事務處理沒有記憶能力。缺乏狀態意味着若是後續處理須要前面的信息
也就是說,當客戶端一次HTTP請求完成之後,客戶端再發送一次HTTP請求,HTTP並不知道當前客戶端是一個」老用戶「。
可使用Cookie來解決無狀態的問題,Cookie就至關於一個通行證,第一次訪問的時候給客戶端發送一個Cookie,當客戶端再次來的時候,拿着Cookie(通行證),那麼服務器就知道這個是」老用戶「
URI,是uniform resource identifier,統一資源標識符,用來惟一的標識一個資源。
Web上可用的每種資源如HTML文檔、圖像、視頻片斷、程序等都是一個來URI來定位的
URI通常由三部組成:
①訪問資源的命名機制
②存放資源的主機名
③資源自身的名稱,由路徑表示,着重強調於資源。
URL是uniform resource locator,統一資源定位器,它是一種具體的URI,即URL能夠用來標識一個資源,並且還指明瞭如何locate這個資源。
URL是Internet上用來描述信息資源的字符串,主要用在各類WWW客戶程序和服務器程序上,特別是著名的Mosaic。
採用URL能夠用一種統一的格式來描述各類信息資源,包括文件、服務器的地址和目錄等。URL通常由三部組成:
①協議(或稱爲服務方式)
②存有該資源的主機IP地址(有時也包括端口號)
③主機資源的具體地址。如目錄和文件名等
200:請求被正常處理
204:請求被受理但沒有資源能夠返回
206:客戶端只是請求資源的一部分,服務器只對請求的部分資源執行GET方法,相應報文中經過Content-Range指定範圍的資源。
301:永久性重定向
302:臨時重定向
303:與302狀態碼有類似功能,只是它但願客戶端在請求一個URI的時候,能經過GET方法重定向到另外一個URI上
304:發送附帶條件的請求時,條件不知足時返回,與重定向無關
307:臨時重定向,與302相似,只是強制要求使用POST方法
400:請求報文語法有誤,服務器沒法識別
401:請求須要認證
403:請求的對應資源禁止被訪問
404:服務器沒法找到對應資源
500:服務器內部錯誤
503:服務器正忙
我下面就簡要歸納一下:
TCP複用:TCP鏈接複用是將多個客戶端的HTTP請求複用到一個服務器端TCP鏈接上,而HTTP複用則是一個客戶端的多個HTTP請求經過一個TCP鏈接進行處理。前者是負載均衡設備的獨特功能;然後者是HTTP 1.1協議所支持的新功能
內容緩存:將常常用到的內容進行緩存起來,那麼客戶端就能夠直接在內存中獲取相應的數據了。
壓縮:將文本數據進行壓縮,減小帶寬
SSL加速(SSL Acceleration):使用SSL協議對HTTP協議進行加密,在通道內加密並加速
TCP緩衝:經過採用TCP緩衝技術,能夠提升服務器端響應時間和處理效率,減小因爲通訊鏈路問題給服務器形成的鏈接負擔。
區別一:
get重點在從服務器上獲取資源,post重點在向服務器發送數據;
區別二:
get傳輸數據是經過URL請求,以field(字段)= value的形式,置於URL後,並用"?"鏈接,多個請求數據間用"&"鏈接,如http://127.0.0.1/Test/login.action?name=admin&password=admin,這個過程用戶是可見的;
post傳輸數據經過Http的post機制,將字段與對應值封存在請求實體中發送給服務器,這個過程對用戶是不可見的;
區別三:
Get傳輸的數據量小,由於受URL長度限制,但效率較高;
Post能夠傳輸大量數據,因此上傳文件時只能用Post方式;
區別四:
get是不安全的,由於URL是可見的,可能會泄露私密信息,如密碼等;
post較get安全性較高;
區別五:
get方式只能支持ASCII字符,向服務器傳的中文字符可能會亂碼。
post支持標準字符集,能夠正確傳遞中文字符。
請求報文包含三部分:
a、請求行:包含請求方法、URI、HTTP版本信息
b、請求首部字段
c、請求內容實體
響應報文包含三部分:
a、狀態行:包含HTTP版本、狀態碼、狀態碼的緣由短語
b、響應首部字段
c、響應內容實體
(1)、Cookie保存在客戶端,未設置存儲時間的Cookie,關閉瀏覽器會話Cookie就會被刪除;設置了存儲時間的Cookie保存在用戶設備的磁盤中知道過時,同時Cookie在客戶端因此能夠僞造,不是十分安全,敏感數據不易保存。Session保存在服務器端,存儲在IIS的進程開闢的內存中,而Session過多會消耗服務器資源,因此儘可能少使用Session。
(2)、Session是服務器用來跟蹤用戶的一種手段,每一個Session都有一個惟一標識:session ID。當服務端生成一個Session時就會向客戶端發送一個Cookie保存到客戶端,這個Cookie保存的是Session的SessionId這樣才能保證客戶端發起請求後,用戶可以與服務器端成千上萬的Session進行匹配,同時也保證了不一樣頁面之間傳值的正確性.
(3)、存儲數據類型不一樣:Session可以存儲任意的JAVA對象,Cookie只能存儲String類型的對象。
(4)、長於10K的數據,不要用到Cookies。
http的請求報文是什麼樣的?
請求報文有4部分組成:
請求報文有4部分組成:
HTTP/1.1 200 OK
。內容不少,重點看標『✨』內容
通用首部字段(General Header Fields):請求報文和響應報文兩方都會使用的首部
請求首部字段(Reauest Header Fields):客戶端向服務器發送請求的報文時使用的首部
響應首部字段(Response Header Fields):從服務器向客戶端響應時使用的字段
實體首部字段(Entiy Header Fields):針對請求報文和響應報文的實體部分使用首部
內容不少,重點看標『✨』內容
2XX 成功
3XX 重定向
4XX 客戶端錯誤
5XX 服務器錯誤
302是http1.0的協議狀態碼,在http1.1版本的時候爲了細化302狀態碼又出來了兩個303和307。
303明確表示客戶端應當採用get方法獲取資源,他會把POST請求變爲GET請求進行重定向。 307會遵守瀏覽器標準,不會從post變爲get。
在早期的HTTP/1.0中,每次http請求都要建立一個鏈接,而建立鏈接的過程須要消耗資源和時間,爲了減小資源消耗,縮短響應時間,就須要重用鏈接。在後來的HTTP/1.0中以及HTTP/1.1中,引入了重用鏈接的機制,就是在http請求頭中加入Connection: keep-alive來告訴對方這個請求響應完成後不要關閉,下一次我們還用這個請求繼續交流。協議規定HTTP/1.0若是想要保持長鏈接,須要在請求頭中加上Connection: keep-alive。
keep-alive的優勢:
幀:HTTP/2 數據通訊的最小單位消息:指 HTTP/2 中邏輯上的 HTTP 消息。例如請求和響應等,消息由一個或多個幀組成。
流:存在於鏈接中的一個虛擬通道。流能夠承載雙向消息,每一個流都有一個惟一的整數ID
HTTP/2 採用二進制格式傳輸數據,而非 HTTP 1.x 的文本格式,二進制協議解析起來更高效。
服務端能夠在發送頁面HTML時主動推送其它資源,而不用等到瀏覽器解析到相應位置,發起請求再響應。例如服務端能夠主動把JS和CSS文件推送給客戶端,而不須要客戶端解析HTML時再發送這些請求。
服務端能夠主動推送,客戶端也有權利選擇是否接收。若是服務端推送的資源已經被瀏覽器緩存過,瀏覽器能夠經過發送RST_STREAM幀來拒收。主動推送也遵照同源策略,服務器不會隨便推送第三方資源給客戶端。
HTTP/1.x會在請求和響應中中重複地攜帶不常改變的、冗長的頭部數據,給網絡帶來額外的負擔。
你能夠理解爲只發送差別數據,而不是所有發送,從而減小頭部的信息量
HTTP 1.x 中,若是想併發多個請求,必須使用多個 TCP 連接,且瀏覽器爲了控制資源,還會對單個域名有 6-8個的TCP連接請求限制。
HTTP2中:
HTTPS ,實際就是在 TCP 層與 HTTP 層之間加入了 SSL/TLS 來爲上層的安全保駕護航,主要用到對稱加密、非對稱加密、證書,等技術進行客戶端與服務器的數據加密傳輸,最終達到保證整個通訊的安全性。
https是安全版的http,由於http協議的數據都是明文進行傳輸的,因此對於一些敏感信息的傳輸就很不安全,HTTPS就是爲了解決HTTP的不安全而生的。
過程比較複雜,咱們得先理解兩個概念
對稱加密:即通訊的雙方都使用同一個祕鑰進行加解密,好比特務接頭的暗號,就屬於對稱加密
對稱加密雖然很簡單性能也好,可是沒法解決首次把祕鑰發給對方的問題,很容易被hacker攔截祕鑰。
非對稱加密:
非對稱加密雖然安全性更高,可是帶來的問題就是速度很慢,影響性能。
解決方案:
那麼結合兩種加密方式,將對稱加密的密鑰使用非對稱加密的公鑰進行加密,而後發送出去,接收方使用私鑰進行解密獲得對稱加密的密鑰,而後雙方可使用對稱加密來進行溝通。
此時又帶來一個問題,中間人問題:
若是此時在客戶端和服務器之間存在一箇中間人,這個中間人只須要把本來雙方通訊互發的公鑰,換成本身的公鑰,這樣中間人就能夠輕鬆解密通訊雙方所發送的全部數據。
因此這個時候須要一個安全的第三方頒發證書(CA),證實身份的身份,防止被中間人攻擊。
證書中包括:簽發者、證書用途、使用者公鑰、使用者私鑰、使用者的HASH算法、證書到期時間等
可是問題來了,若是中間人篡改了證書,那麼身份證實是否是就無效了?這個證實就白買了,這個時候須要一個新的技術,數字簽名。
數字簽名就是用CA自帶的HASH算法對證書的內容進行HASH獲得一個摘要,再用CA的私鑰加密,最終組成數字簽名。
當別人把他的證書發過來的時候,我再用一樣的Hash算法,再次生成消息摘要,而後用CA的公鑰對數字簽名解密,獲得CA建立的消息摘要,二者一比,就知道中間有沒有被人篡改了。
這個時候就能最大程度保證通訊的安全了。
消息時的系統通訊,一般基於網絡協議實現。常見的協議包括TCP/IP,UDP/IP。
TCP/IP等協議用於數據傳輸,但要完成通訊,還須要對數據進行處理。例如讀取和寫入數據。
I/O能夠分爲兩種:同步IO和異步IO,同步I/O最多見的是 BIO(Blocking IO)、NIO(Non-Blocking IO)
BIO:是當發起I/O的讀或寫操做時,均爲阻塞方式,直到應用程序讀到了流或者將流寫入數據。
NIO:基於事件驅動思想,常採用reactor(反應器)模式。當發起 IO請求時,應用程序是非阻塞的。當SOCKET有流可讀或寫的時候,
由操做系統通知應用程序,應用程序再將流讀取到緩衝區或者寫入系統。
AIO:一樣基於事件驅動的思想,一般採用Proactor(前攝器模式)實現。對於讀操做,操做系統將數據讀到緩衝區,並通知應用程序,對於寫操做,操做系統將write方法傳遞的流寫入並主動通知
應用程序。它節省了NIO中遍歷事件通知隊列的代價。
阻塞 某個請求發出後,因爲該請求操做須要的條件不知足,請求操做一直阻塞,不會返回,直到條件知足。
非阻塞 請求發出後,若該請求須要的條件不知足,則當即返回一個標誌信息告知條件不知足,而不會一直等待。通常須要經過循環判斷請求條件是否知足來獲取請求結果。
這裏注意比較NIO和AIO的不一樣,AIO是操做系統完成IO並通知應用程序,NIO是操做系統通知應用程序,由應用程序完成。
reactor 模型
當客戶端請求抵達後,服務處理程序使用多路分配策略,由一個非阻塞的線程來接收全部的請求,而後派發這些請求至相關的工做線程進行處理
自上而下是:
應用層(數據):肯定進程之間通訊的性質以知足用戶須要以及提供網絡與用戶應用
表示層(數據):主要解決用戶信息的語法表示問題,如加密解密
會話層(數據):提供包括訪問驗證和會話管理在內的創建和維護應用之間通訊的機制,如服務器驗證用戶登陸即是由會話層完成的
傳輸層(段):實現網絡不一樣主機上用戶進程之間的數據通訊,可靠
與不可靠的傳輸,傳輸層的錯誤檢測,流量控制等
網絡層(包):提供邏輯地址(IP)、選路,數據從源端到目的端的
傳輸
數據鏈路層(幀):將上層數據封裝成幀,用MAC地址訪問媒介,錯誤檢測與修正
物理層(比特流):設備之間比特流的傳輸,物理接口,電氣特性等
TCP/IP協議按照層次分爲如下四層。應用層、傳輸層、網絡層、數據鏈路層。
TCP(Transmission Control Protocol,傳輸控制協議)是面向鏈接的協議,也就是說,在收發數據前,必須和對方創建可靠的鏈接。一個TCP鏈接必需要通過三次「對話」才能創建起來,其中的過程很是複雜,
TCP首部選項字段多達40B,一些經常使用的字段有:
1)選項結束字段(EOP,0x00),佔1B,一個報文段僅用一次。放在末尾用於填充,用途是說明:首部已經沒有更多的消息,應用數據在下一個32位字開始處
2)無操做字段(NOP, 0x01),佔1B,也用於填充,放在選項的開頭
3)MSS(最大報文段長度),格式以下:種類(1B,值爲2),長度(1B,值爲4),數值(2B)
用於在鏈接開始時肯定MSS的大小,若是沒有肯定,就用默認的(通常實現是536B)
4)窗口擴大因子,格式以下:種類(1B,值爲3),長度(1B,值爲3),數值(1B)
新窗口值 = 首部窗口值 * 2的(擴大因子)次方
當通訊雙方認爲首部的窗口值還不夠大的時候,在鏈接開始時用這個來定義更大的窗口。僅在鏈接開始時有效。一經定義,通訊過程當中沒法更改。
5)時間戳(應用測試RTT和防止序號繞回)
6)容許SACK和SACK選項
發送方:我要和你創建連接?
接收方:你真的要和我創建連接麼?
發送方:我真的要和你創建連接,成功。
爲了防止已失效的鏈接請求報文忽然又傳送到了服務端,於是產生錯誤。客戶端發出的鏈接請求報文並未丟失,而是在某個網絡節點長時間滯留了,以至延誤到連接釋放之後的某個時間纔到達 Server 。
1、SYN洪泛攻擊
服務器處於SYN_Wait的狀態:
1)假裝的IP向服務器發送一個SYN請求創建鏈接,而後服務器向該IP回覆SYN和ACK,可是找不到該IP對應的主機,當超時時服務器收不到ACK會重複發送。當大量的攻擊者請求創建鏈接時,服務器就會存在大量未完成三次握手的鏈接,服務器主機backlog被耗盡而不能響應其它鏈接。即SYN泛洪攻擊 (屬於DOS的一種,發送大量的半鏈接請求,耗費CPU和內存資源,引發網絡堵塞甚至系統癱瘓)
當你在服務器上看到大量的半鏈接狀態時,特別是源IP地址是隨機的,基本上能夠判定這是一次SYN攻擊.在Linux下能夠以下命令檢測是否被Syn攻擊
netstat -n -p TCP | grep SYN_RECV
防範措施:
一、下降SYN timeout時間,使得主機儘快釋放半鏈接的佔用
二、採用SYN cookie設置,若是短期內連續收到某個IP的重複SYN請求,則認爲受到了該IP的攻擊,丟棄來自該IP的後續請求報文
三、在網關處設置過濾,拒絕將一個源IP地址不屬於其來源子網的包進行更遠的路由
2)當一個主機向服務器發送SYN請求鏈接,服務器回覆ACK和SYN後,攻擊者截獲ACK和SYN。而後假裝成原始主機繼續與服務器進行通訊。
2、DOS攻擊 拒絕服務攻擊
DDoS(分佈式拒絕服務攻擊)
DOS攻擊利用合理的服務請求佔用過多的服務資源,使正經常使用戶的請求沒法獲得相應。
常見的DOS攻擊有計算機網絡帶寬攻擊和連通性攻擊。
帶寬攻擊指以極大的通訊量衝擊網絡,使得全部可用網絡資源都被消耗殆盡,最後致使合法的用戶請求沒法經過。
連通性攻擊指用大量的鏈接請求衝擊計算機,使得全部可用的操做系統資源都被消耗殆盡,最終計算機沒法再處理合法用戶的請求。
3、死亡值ping
許多操做系統的TCP/IP協議棧規定ICMP包大小爲64KB(網間控制報文),且在對包的標題頭進行讀取以後,要根據該標題頭裏包含的信息來爲有效載荷生成緩衝區。
」死亡值ping」就是故意產生畸形的測試ping包,聲稱本身的尺寸超過ICMP上限,也就是加載的尺寸超過64KB上限,使未採起保護措施的網絡系統出現內存分配錯誤,致使TCP/IP協議棧崩潰,最終接收方宕機。
四次揮手,簡單來講,就是:
發送方:我要和你斷開鏈接!
接收方:好的,斷吧。
接收方:我也要和你斷開鏈接!
發送方:好的,斷吧。
TIME_WAIT狀態存在有兩個緣由。
1、可靠終止TCP鏈接。若是最後一個ACK報文由於網絡緣由被丟棄,此時server由於沒有收到ACK而超時重傳FIN報文,處於TIME_WAIT狀態的client能夠繼續對FIN報文作回覆,向server發送ACK報文。
2、保證讓遲來的TCP報文段有足夠的時間被識別和丟棄。鏈接結束了,網絡中的延遲報文也應該被丟棄掉,以避免影響馬上創建的新鏈接。
爲何常說 TCP 有粘包和拆包的問題而不說 UDP ?
由前兩節可知,UDP 是基於報文發送的,UDP首部採用了 16bit 來指示 UDP 數據報文的長度,所以在應用層能很好的將不一樣的數據報文區分開,從而避免粘包和拆包的問題。
而 TCP 是基於字節流的,雖然應用層和 TCP 傳輸層之間的數據交互是大小不等的數據塊,可是 TCP 並無把這些數據塊區分邊界,僅僅是一連串沒有結構的字節流;另外從 TCP 的幀結構也能夠看出,在 TCP 的首部沒有表示數據長度的字段,基於上面兩點,在使用 TCP 傳輸數據時,纔有粘包或者拆包現象發生的可能。
什麼是粘包、拆包?
假設 Client 向 Server 連續發送了兩個數據包,用 packet1 和 packet2 來表示,那麼服務端收到的數據能夠分爲三種狀況,現列舉以下:
第一種狀況,接收端正常收到兩個數據包,即沒有發生拆包和粘包的現象。
第二種狀況,接收端只收到一個數據包,可是這一個數據包中包含了發送端發送的兩個數據包的信息,這種現象即爲粘包。這種狀況因爲接收端不知道這兩個數據包的界限,因此對於接收端來講很難處理。
第三種狀況,這種狀況有兩種表現形式,以下圖。接收端收到了兩個數據包,可是這兩個數據包要麼是不完整的,要麼就是多出來一塊,這種狀況即發生了拆包和粘包。這兩種狀況若是不加特殊處理,對於接收端一樣是很差處理的。
爲何會發生 TCP 粘包、拆包?
粘包、拆包解決辦法
因爲 TCP 自己是面向字節流的,沒法理解上層的業務數據,因此在底層是沒法保證數據包不被拆分和重組的,這個問題只能經過上層的應用協議棧設計來解決,根據業界的主流協議的解決方案,概括以下:
窗口是緩存的一部分,用來暫時存放字節流。發送方和接收方各有一個窗口,接收方經過 TCP 報文段中的窗口字段告訴發送方本身的窗口大小,發送方根據這個值和其它信息設置本身的窗口大小。
發送窗口內的字節都容許被髮送,接收窗口內的字節都容許被接收。若是發送窗口左部的字節已經發送而且收到了確認,那麼就將發送窗口向右滑動必定距離,直到左部第一個字節不是已發送而且已確認的狀態;接收窗口的滑動相似,接收窗口左部字節已經發送確認並交付主機,就向右滑動接收窗口。
接收窗口只會對窗口內最後一個按序到達的字節進行確認,例如接收窗口已經收到的字節爲 {31, 34, 35},其中 {31} 按序到達,而 {34, 35} 就不是,所以只對字節 31 進行確認。發送方獲得一個字節的確認以後,就知道這個字節以前的全部字節都已經被接收。
流量控制是爲了控制發送方發送速率,保證接收方來得及接收。
接收方發送的確認報文中的窗口字段能夠用來控制發送方窗口大小,從而影響發送方的發送速率。將窗口字段設置爲 0,則發送方不能發送數據。
實際上,爲了不此問題的產生,發送端主機會時不時的發送一個叫作窗口探測的數據段,此數據段僅包含一個字節來獲取最新的窗口大小信息。
UDP(User Data Protocol,用戶數據報協議),是與 TCP 相對應的協議。它是面向非鏈接的協議,它不與對方創建鏈接,而是直接就把數據包發送過去。
UDP 是無鏈接的。
UDP 使用盡最大努力交付,即不保證可靠交付,所以主機不須要維持複雜的連接狀態(這裏面有許多參數)。
UDP 是面向報文的。
UDP 沒有擁塞控制,所以網絡出現擁塞不會使源主機的發送速率下降。
TCP 是面向鏈接的;UDP 是無鏈接的。
TCP 是可靠的;UDP 是不可靠的。
TCP 只支持點對點通訊;UDP 支持一對1、一對多、多對1、多對多的通訊模式。
TCP 是面向字節流的;UDP 是面向報文的。
TCP 有擁塞控制機制;UDP 沒有擁塞控制,適合媒體通訊。
TCP 首部開銷(20 個字節),比 UDP 的首部開銷(8 個字節)要大。
用戶數據報協議 UDP(User Datagram Protocol)
是無鏈接的,盡最大可能交付,沒有擁塞控制,面向報文(對於應用程序傳下來的報文不合並也不拆分,只是添加 UDP 首部),支持一對1、一對多、多對一和多對多的交互通訊。
傳輸控制協議 TCP(Transmission Control Protocol)
是面向鏈接的,提供可靠交付,有流量控制,擁塞控制,提供全雙工通訊,面向字節流(把應用層傳下來的報文當作字節流,把字節流組織成大小不等的數據塊),每一條 TCP 鏈接只能是點對點的(一對一)。
UDP 首部字段以下:
UDP 首部字段只有 8 個字節,包括源端口、目的端口、長度、檢驗和。12 字節的僞首部是爲了計算檢驗和臨時添加的。
TCP 首部字段以下:
TCP 首部格式比 UDP 複雜。
序號:用於對字節流進行編號,例如序號爲 301,表示第一個字節的編號爲 301,若是攜帶的數據長度爲 100 字節,那麼下一個報文段的序號應爲 401。
確認號:指望收到的下一個報文段的序號。例如 B 正確收到 A 發送來的一個報文段,序號爲 501,攜帶的數據長度爲 200 字節,所以 B 指望下一個報文段的序號爲 701,B 發送給 A 的確認報文段中確認號就爲 701。
數據偏移:指的是數據部分距離報文段起始處的偏移量,實際上指的是首部的長度。
控制位:八位從左到右分別是 CWR,ECE,URG,ACK,PSH,RST,SYN,FIN。
CWR:CWR 標誌與後面的 ECE 標誌都用於 IP 首部的 ECN 字段,ECE 標誌爲 1 時,則通知對方已將擁塞窗口縮小;
ECE:若其值爲 1 則會通知對方,從對方到這邊的網絡有阻塞。在收到數據包的 IP 首部中 ECN 爲 1 時將 TCP 首部中的 ECE 設爲 1;
URG:該位設爲 1,表示包中有須要緊急處理的數據,對於須要緊急處理的數據,與後面的緊急指針有關;
ACK:該位設爲 1,確認應答的字段有效,TCP規定除了最初創建鏈接時的 SYN 包以外該位必須設爲 1;
PSH:該位設爲 1,表示須要將收到的數據馬上傳給上層應用協議,若設爲 0,則先將數據進行緩存;
RST:該位設爲 1,表示 TCP 鏈接出現異常必須強制斷開鏈接;
SYN:用於創建鏈接,該位設爲 1,表示但願創建鏈接,並在其序列號的字段進行序列號初值設定;
FIN:該位設爲 1,表示從此再也不有數據發送,但願斷開鏈接。當通訊結束但願斷開鏈接時,通訊雙方的主機之間就能夠相互交換 FIN 位置爲 1 的 TCP 段。
每一個主機又對對方的 FIN 包進行確認應答以後能夠斷開鏈接。不過,主機收到 FIN 設置爲 1 的 TCP 段以後沒必要立刻回覆一個 FIN 包,而是能夠等到緩衝區中的全部數據都由於已成功發送而被自動刪除以後再發 FIN 包;
窗口:窗口值做爲接收方讓發送方設置其發送窗口的依據。之因此要有這個限制,是由於接收方的數據緩存空間是有限的。