【參展預(yù)告】2025.9.15-17山東電力展，愛陸通B3館A7···
工業(yè)級路由器防護標準
集中式DTU通信解決方案-智能配網(wǎng)
5G視頻RTU 視頻數(shù)采儀 數(shù)據(jù)采集傳輸儀
一、TCP協(xié)議：
位于傳輸層， 提供可靠的字節(jié)流服務(wù)。所謂的字節(jié)流服務(wù)（Byte Stream Service） 是指， 為了方便傳輸， 將大塊數(shù)據(jù)分割成以報文段（segment） 為單位的數(shù)據(jù)包進行管理。 而可靠的傳輸服務(wù)是指， 能夠把數(shù)據(jù)準確可靠地傳給對方。 即TCP 協(xié)議為了更容易傳送大數(shù)據(jù)才把數(shù)據(jù)分割， 而且 TCP 協(xié)議能夠確認數(shù)據(jù)最終是否送達到對方。所以，TCP連接相當于兩根管道（一個用于服務(wù)器到客戶端，一個用于客戶端到服務(wù)器），管道里面數(shù)據(jù)傳輸是通過字節(jié)碼傳輸，傳輸是有序的，每個字節(jié)都是一個一個來傳輸。
(1)、三次握手：握手過程中使用了 TCP 的標志（flag） —— SYN（synchronize） 和ACK（acknowledgement） 。
第一次握手：建立連接時，客戶端A發(fā)送SYN包（SYN=j）到服務(wù)器B，并進入SYN_SEND狀態(tài)，等待服務(wù)器B確認。
第二次握手：服務(wù)器B收到SYN包，必須確認客戶A的SYN（ACK=j+1），同時自己也發(fā)送一個SYN包（SYN=k），即SYN+ACK包，此時服務(wù)器B進入SYN_RECV狀態(tài)。
第三次握手：客戶端A收到服務(wù)器B的SYN＋ACK包，向服務(wù)器B發(fā)送確認包ACK（ACK=k+1），此包發(fā)送完畢，完成三次握手。
若在握手過程中某個階段莫名中斷， TCP 協(xié)議會再次以相同的順序發(fā)送相同的數(shù)據(jù)包。
（2）、四次揮手：由于TCP連接是全雙工的，因此每個方向都必須單獨進行關(guān)閉。這個原則是當一方完成它的數(shù)據(jù)發(fā)送任務(wù)后就能發(fā)送一個FIN來終止這個方向的連接。收到一個 FIN只意味著這一方向上沒有數(shù)據(jù)流動，一個TCP連接在收到一個FIN后仍能發(fā)送數(shù)據(jù)。先進行關(guān)閉的一方將執(zhí)行主動關(guān)閉，而另一方被動關(guān)閉。
客戶端A發(fā)送一個FIN，用來關(guān)閉客戶A到服務(wù)器B的數(shù)據(jù)傳送。
服務(wù)器B收到這個FIN，它發(fā)回一個ACK，確認序號為收到的序號加1。
服務(wù)器B關(guān)閉與客戶端A的連接，發(fā)送一個FIN給客戶端A。
客戶端A發(fā)回ACK報文確認，并將確認序號設(shè)置為收到序號加1。
三次握手和四次揮手：在TCP連接中，服務(wù)器端的SYN和ACK向客戶端發(fā)送是一次性發(fā)送的，而在斷開連接的過程中， B端向A
端發(fā)送的ACK和FIN是分兩次發(fā)送的。因為在B端接收到A端的FIN后， B端可能還有數(shù)據(jù)要傳輸，所以先發(fā)送ACK，等B端處理完自己的事情后就可以發(fā)送FIN斷開連接了。
（3）、深入理解TCP連接：
由于TCP是全雙工的，因此在每一個方向都必須單獨關(guān)閉。這原則是當一方完成它的數(shù)據(jù)發(fā)送任務(wù)后就能發(fā)送一個FIN來終止這個方向的連接。收到一個FIN只意味著這個方向上沒有數(shù)據(jù)流動，一個TCP連接在接收到一個FIN后仍能發(fā)送數(shù)據(jù)。 首先進行關(guān)
閉的一方將執(zhí)行主動關(guān)閉，而另一方執(zhí)行被動關(guān)閉。
TCP協(xié)議的連接是全雙工連接，一個TCP連接存在雙向的讀寫通道。簡單來說，是“先關(guān)讀，再關(guān)寫” ，總共需要4個階段。以客戶機發(fā)起關(guān)閉連接為例：1.服務(wù)器讀通道關(guān)閉；2.客戶端寫通道關(guān)閉；3.客戶端讀通道關(guān)閉；4.服務(wù)器寫通道關(guān)閉。
關(guān)閉行為是在發(fā)起方數(shù)據(jù)發(fā)送完畢之后，給對方發(fā)出一個FIN（finish）數(shù)據(jù)段，直到接收到對方發(fā)送的FIN,且對方收到了接收確認的ACK之后，雙方的數(shù)據(jù)通信完全結(jié)束，過程中每次都需要返回確認數(shù)據(jù)段ACK。
（4）、TCP使用滑動窗口機制來進行流量控制。
建立連接時，各端分配一個緩沖區(qū)用來存儲接收的數(shù)據(jù)，并將緩沖區(qū)的尺寸發(fā)送給另一端。接收方發(fā)送的確認消息中包含了自己剩余的緩沖區(qū)尺寸。剩余緩沖區(qū)空間的數(shù)量叫做窗口。其實就是建立連接的雙虎互相知道彼此剩余的緩沖區(qū)大小。
（5）、擁塞控制
擁塞控制：防止過多的數(shù)據(jù)注入到網(wǎng)路中，這樣可以使網(wǎng)絡(luò)中的路由器或鏈路不至于阻塞。擁塞控制是一個全局性的過程，和流量控制不同，流量控制是點對點的控制。
1、慢開始：發(fā)送方維持一個叫做擁塞窗口cwnd（congestion window）的狀態(tài)變量。擁塞窗口的大小取決于網(wǎng)絡(luò)的擁塞程度，并且動態(tài)的變化。發(fā)送方讓自己的發(fā)送窗口等于擁塞窗口，另外考慮到接收方的接收能力，發(fā)送窗口可能小于擁塞窗口。思路就是：不要一開始就發(fā)送大量的數(shù)據(jù)，先試探一下網(wǎng)絡(luò)的擁塞程度，也就是說由小到大增加擁塞窗口的大小。
為了防止cwnd增長過大引起網(wǎng)絡(luò)擁塞，還需要設(shè)置一個慢開始門限ssthresh狀態(tài)變量。 ssthresh的方法如下：
當cwnd < ssthresh時，開始使用慢開始算法；當cwnd > ssthresh, 改用擁塞避免算法；當cwnd = ssthresh時，慢開始與擁塞算法任意。
2.擁塞避免：
擁塞避免算法讓擁塞窗口緩慢增長，即每經(jīng)過一個往返時間RTT就把發(fā)送方的擁塞窗口cwnd加1，而不是加倍，這樣擁塞窗口按照線性規(guī)律緩慢增長。無論是在慢開始階段還是在擁塞避免階段，只要發(fā)送方判斷網(wǎng)絡(luò)出現(xiàn)擁塞（其根據(jù)就是沒有收到確認，雖然沒有收到確認可能是其他原因的分組丟失，但是因為?法判定，所以都當作擁塞處理），就把慢開始門限設(shè)置為出現(xiàn)擁塞時的發(fā)送窗口的一半，然后把擁塞窗口設(shè)置為1，執(zhí)行慢開始算法：
此外，還有快速重傳和快速恢復(fù)，停止-等待協(xié)議，回退N幀協(xié)議，選擇重傳協(xié)議等。
二、UDP協(xié)議：
無連接協(xié)議，也稱透明協(xié)議，也位于傳輸層。
兩者區(qū)別：
1） TCP提供面向連接的傳輸，通信前要先建立連接（三次握手機制）； UDP提供無連接的傳輸，通信前不需要建立連接。
2） TCP提供可靠的傳輸（有序，無差錯，不丟失，不重復(fù)）； UDP提供不可靠的傳輸。
3） TCP面向字節(jié)流的傳輸，因此它能將信息分割成組，并在接收端將其重組； UDP是面向數(shù)據(jù)報的傳輸，沒有分組開銷。
4） TCP提供擁塞控制和流量控制機制； UDP不提供擁塞控制和流量控制機制。
三、長連接和短連接
HTTP的長連接和短連接本質(zhì)上是TCP長連接和短連接。HTTP屬于應(yīng)用層協(xié)議，在傳輸層使用TCP協(xié)議，在網(wǎng)絡(luò)層使用IP協(xié)議。 IP協(xié)議主要解決網(wǎng)絡(luò)路由和尋址問題，TCP協(xié)議主要解決如何在IP層之上可靠地傳遞數(shù)據(jù)包，使得網(wǎng)絡(luò)上接收端收到發(fā)送端所發(fā)出的所有包，并且順序與發(fā)送順序一致。TCP協(xié)議是可靠的、面向連接的。
在HTTP/1.0中默認使用短連接。也就是說，客戶端和服務(wù)器每進行一次HTTP操作，就建立一次連接，任務(wù)結(jié)束就中斷連接。當客戶端瀏覽器訪問的某個HTML或其他類型的Web頁中包含有其他的Web資源（如JavaScript文件、圖像文件、CSS文件等），每遇到這樣一個Web資源，瀏覽器就會重新建立一個HTTP會話。
而從HTTP/1.1起，默認使用長連接，用以保持連接特性。使用長連接的HTTP協(xié)議，會在響應(yīng)頭加入這行代碼：
Connection:keep-alive
在使用長連接的情況下，當一個網(wǎng)頁打開完成后，客戶端和服務(wù)器之間用于傳輸HTTP數(shù)據(jù)的TCP連接不會關(guān)閉，客戶端再次訪問這個服務(wù)器時，會繼續(xù)使用這一條已經(jīng)建立的連接。Keep-Alive不會永久保持連接，它有一個保持時間，可以在不同的服務(wù)器軟件（如Apache）中設(shè)定這個時間。實現(xiàn)長連接需要客戶端和服務(wù)端都支持長連接。
HTTP協(xié)議的長連接和短連接，實質(zhì)上是TCP協(xié)議的長連接和短連接。
