『壹』 Web階段——TCP/UDP區別
2018-09-25
全稱：Transmission Control Protocol（傳輸控制協議），是工作在OSI七層模型(Open System Interconnect，開放式系統互聯)中的傳輸層，是一種面向連接的、可靠的、基於位元組流的通信協議。
TCP層將應用層的數據流分成報文段，再繼續向網路層傳輸。為了數據傳輸的可靠性，TCP層將每個報文段進行了編號，用來保證接收端數據的我完整性。
TCP層每傳輸一個報文段，就向接收端發送一次確認信息。在一定時間內，如果接收端沒有返回確認信息，發送端將重新發送丟失的報文。
全稱：User Datagram Protocol（用戶數據報協議），與TCP一樣工作在傳輸層，是一種面向無連接的、不可靠的通信協議。
UDP僅將應用層的數據流分成報文直接進行傳輸，不進行排序。數據安全沒有保障，但操作效率高，適合普通數據傳輸（QQ）。
連接時：
1. 客戶端向伺服器發送一個SYN置位的TCP報文，其中包含連接的初始序列號x和一個窗口大小（表示客戶端上用來存儲從伺服器發送來的傳入段的緩沖區的大小）。
2. 伺服器收到客戶端發送過來的SYN報文後，向客戶端發送一個SYN和ACK都置位的TCP報文，其中包含它選擇的初始序列號y、對客戶端的序列號的確認x+1和一個窗口大小（表示伺服器上用來存儲從客戶端發送來的傳入段的緩沖區的大小）。
3. .客戶端接收到伺服器端返回的SYN+ACK報文後，向伺服器端返回一個確認號y+1和序號x+1的ACK報文，一個標準的TCP連接完成。
＃TCP斷開連接四次揮手過程：
1. Client端發起中斷連接請求，也就是發送FIN報文。
2. Server端接到FIN報文後，意思是說"我Client端沒有數據要發給你了"，但是如果你還有數據沒有發送完成，則不必急著關閉Socket，可以繼續發送數據。所以你先發送ACK，"告訴Client端，你的請求我收到了，但是我還沒准備好，請繼續你等我的消息"。
3. 這個時候Client端就進入FIN_WAIT狀態，繼續等待Server端的FIN報文。當Server端確定數據已發送完成，則向Client端發送FIN報文，"告訴Client端，好了，我這邊數據發完了，准備好關閉連接了"。
4. Client端收到FIN報文後，"就知道可以關閉連接了，但是他還是不相信網路，怕Server端不知道要關閉，所以發送ACK後進入TIME_WAIT狀態，如果Server端沒有收到ACK則可以重傳。「，Server端收到ACK後，"就知道可以斷開連接了"。Client端等待了2MSL後依然沒有收到回復，則證明Server端已正常關閉，那好，我Client端也可以關閉連接了。Ok，TCP連接就這樣關閉了！
本文來自 tensorzhl 的CSDN 博客 ，全文地址請點擊： https://blog.csdn.net/tensorzhl/article/details/75797364?utm_source=
『貳』 【web】TCP和UDP、HTTP的區別
（1） TCP是面向連接的，UDP是無連接的 ，即發送數據前不需要先建立鏈接。
（2） TCP提供可靠的服務 。也就是說，通過TCP連接傳送的數據，無差錯，不丟失，不重復，且按序到達；UDP盡最大努力交付，即不保證可靠交付。 並且因為tcp可靠，面向連接，不會丟失數據因此適合大數據量的交換。
（3） TCP是面向位元組流，UDP面向報文 ，並且網路出現擁塞不會使得發送速率降低（因此會出現丟包，對實時的應用比如IP電話和視頻會議等）。
（4） TCP只能是1對1的，UDP支持1對1、1對多 。
（5） TCP的首部較大 為20位元組，而UDP只有8位元組。
（6）TCP是面向連接的可靠性傳輸，而UDP是不可靠的。
（7） TCP和UDP都是傳輸層的協議，HTTP是在應用層的一個協議
（8）HTTP協議基於請求\響應模型的，並且是 基於TCP協議 的。
HTTP協議是建立在請求/響應模型上的。首先由客戶建立一條與伺服器的TCP鏈接，並發送一個請求到伺服器，請求中包含請求方法、URL、協議版本以及相關的MIME樣式的消息。伺服器響應一個狀態行，包含消息的協議版本、一個成功和失敗碼以及相關的MIME式樣的消息。
（9）HTTP/1.0為 多次的TCP 鏈接，HTTP/1.1提出了可持續鏈接即只建立 一次TCP鏈接 。
因此一個包含HTML內容和圖片的頁面將需要建立多次的短期的TCP鏈接。一次TCP鏈接的建立將需要3次握手。另外，為了獲得適當的傳輸速度，則需要TCP花費額外的迴路鏈接時間（RTT）。每一次鏈接的建立需要這種經常性的開銷，而其並不帶有實際有用的數據，只是保證鏈接的可靠性，因此HTTP/1.1提出了可持續鏈接的實現方法。HTTP/1.1將只建立一次TCP的鏈接而重復地使用它傳輸一系列的請求/響應消息，因此減少了鏈接建立的次數和經常性的鏈接開銷。
『叄』 如何讓自己的產品快速實現北斗短報文功能
從技術層面來分析，舉一個例子：海聊開發者平台，一個極力於為開發者實現「零門檻」的快速接入使用北斗短報文通信服務的平台。構建了穩定的北斗短報文通信服務站，硬體多卡通道與雲服務的配合，數據的安全與雲備份，抽離提取的簡易的SDK，是基於簡單快速、靈活，通信速度快的HTTP協議。HTTP協議作為Web開發的基礎一直被大多數人所熟知，一次WEB資源請求的過程，其實就和一次方法調用特別相似。
注冊成為了開發北斗開發者，獲取相應的授權使用的參數，調用介面：1）發送北斗短報文。 2）接受北斗短報文。是不是簡單又快捷，也許僅僅只需要簡簡單單幾分鍾，你就能為應用接入了最基礎短報文的功能。
『肆』 計算機網路——應用層-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（谷歌，微軟）
『伍』 javaweb里get請求頭報文信息含義是什麼啊
常見的HTTP報文頭屬性
Accpet
告訴服務端,客戶端接收什麼類型的響應
Referer
表示這是請求是從哪個URL進來的,比如想在網上購物,但是不知道選擇哪家電商平台,你就去問度娘,說哪家電商的東西便宜啊,然後一堆東西彈出在你面前,第一給就是某寶,當你從這里進入某寶的時候,這個請求報文的Referer就是www..com
Cache-Control
對緩存進行控制,如一個請求希望響應的內容在客戶端緩存一年,或不被緩可以通過這個報文頭設置
Accept-Encoding
例如:Accept-Encoding:gzip, deflate(這兩種都是壓縮格式)
這個屬性是用來告訴伺服器能接受什麼編碼格式,包括字元編碼,壓縮形式(一般都是壓縮形式)
Host
指定要請求的資源所在的主機和埠
User-Agent 作用：告訴伺服器，客戶端使用的操作系統、瀏覽器版本和名稱
『陸』 Web 瀏覽器向偵聽標准埠的 Web 伺服器發出請求之後，在伺服器響應的 TCP 報頭中，源埠號是多少
當然是80埠了。標准web應用必然是採用80埠，響應報文源埠就是指伺服器埠，所以肯定是80埠。
『柒』 web伺服器上一個大小為22KB的網頁，假設TCP最大報文長度是1KB,瀏覽器與web伺服器之間的往返RTT為100ms
客戶端C和伺服器S之間建立一個TCP連接，該連接總是以1KB的最大段長發送TCP段，客戶端C有足夠的數據要發送。當擁塞窗口為16KB的時候發生超時，如果接下來的4個RTT往返時間內的TCP段的傳輸是成功的，那麼當第4個RTT時間內發送的所有TCP段都得到了ACK時，擁塞窗口大小是：9KB
『捌』 WEB揭秘之長連接，短連接，長輪詢，短輪詢
客戶端與服務端之間建立通信需要經過該三次握手：
客戶端建立連接（發送syn報文）->服務端發送確認信息(發送syn+ack報文）->客戶端接收確認信息。因此通過tcp建立了客戶端與服務端的連接。
http通信通過tcp建立連接一般都是短連接，客戶端與伺服器之間建立了一次通信後就要斷開連接，當再次需要進行通信的時候就要再次通過tcp建立連接.
通過tcp建立Http長連接，就解決了短連接的弊端，當建立了客戶端和伺服器端的連接後，就會保持這個連接，但是不會斷開，後續通信可繼續使用這個長連接。但是長連接會對伺服器端造成非常大的壓力，因為長連接不關閉的話會越來越多。解決這種風險可以設置最大長連接數，伺服器端也可以關閉一些長時間無操作的連接。
短輪詢是建立在http通信的基礎上。當伺服器端的數據在實時更新想要向客戶端推送時，就會用到輪詢這種方式。因為客戶端只能主動向伺服器端發送請求獲取數據,但是要服務端主動發送數據給客戶端，就可以在客戶端不斷的發送請求給伺服器端，伺服器端不管有沒有數據都會返回數據。保持客戶端不斷發送請求的方法是設置一個定時器不斷調用某個函數.
然而短輪詢的缺點也顯而易見，這樣不斷的請求數據就會造成伺服器端的壓力，並且如果設置超時過短就會獲得臟數據.
長輪詢是對短輪詢的一種提升，當客戶端不斷地向伺服器端請求數據的時候，若有數據則返回，沒有數據返回的情況都要hold on ，直到timeout。這種解決辦法一定程度上解決了伺服器端的壓力，但是如果進程過多，也會成為問題.
這是最近對瀏覽一些博客最基本的了解，以後如果有更深層次的了解將會繼續修改。
『玖』 webrtc P2P之turn協議介紹
TURN的全稱為Traversal Using Relays around NAT，是STUN/RFC5389的一個拓展，主要添加了Relay功能。如果終端在NAT之後，那麼在特定的情景下，有可能使得終端無法和其對等端（peer）進行直接的通信，這時就需要公網的伺服器作為一個中繼， 對來往的數據進行轉發。這個轉發的協議就被定義為TURN。TURN和其他中繼協議的不同之處在於，它允許客戶端使用同一個中繼地址（relay address）與多個不同的peer進行通信。
使用TURN協議的客戶端必須能夠通過中繼地址和對等端進行通訊，並且能夠得知每個peer的的IP地址和埠（確切地說，應該是peer的伺服器反射地址）。而這些行為如何完成，是不在TURN協議范圍之內的。其中一個可用的方式是客戶端通過email來告知對等端信息，另一種方式是客戶端使用一些指定的協議，如「introction」 或 「rendezvous」，詳見RFC5128
如果TURN使用於ICE協議中，relay地址會作為一個候選，由ICE在多個候選中進行評估，選取最合適的通訊地址。一般來說中繼的優先順序都是最低的。TURN協議被設計為ICE協議(Interactive Connectivity Establishment)的一部分，而且也強烈建議用戶在他們的程序里使用ICE，但是也可以獨立於ICE的運行。值得一提的是，TURN協議本身是STUN的一個拓展，因此絕大部分TURN報文都是STUN類型的，作為STUN的一個拓展，TURN增加了新的方法（method）和屬性（attribute）。
在典型的情況下，TURN客戶端連接到內網中，並且通過一個或者多個NAT到達公網，TURN伺服器架設在公網中，不同的客戶端以TURN伺服器為中繼和其他peer進行通信，如下圖所示：
在上圖中，左邊的TURN Client是位於NAT後面的一個客戶端（內網地址是10.1.1.2:49721），連接公網的TURN伺服器（默認埠3478）後，伺服器會得到一個Client的反射地址（Reflexive Transport Address, 即NAT分配的公網IP和埠）192.0.2.1:7000，此時Client會通過TURN命令創建或管理ALLOCATION，allocation是伺服器上的一個數據結構，包含了中繼地址的信息。伺服器隨後會給Client分配一個中繼地址，即圖中的192.0.2.15:50000，另外兩個對等端若要通過TURN協議和Client進行通信，可以直接往中繼地址收發數據即可，TURN伺服器會把發往指定中繼地址的數據轉發到對應的Client，這里是其反射地址。
Server上的每一個allocation都唯一對應一個client，並且只有一個中繼地址，因此當數據包到達某個中繼地址時，伺服器總是知道應該將其轉發到什麼地方。但值得一提的是，一個Client可能在同一時間在一個Server上會有多個allocation，這和上述規則是並不矛盾的。
在協議中,TURN伺服器與peer之間的連接都是基於UDP的,但是伺服器和客戶端之間可以通過其他各種連接來傳輸STUN報文,比如TCP/UDP/TLS-over-TCP. 客戶端之間通過中繼傳輸數據時候,如果用了TCP,也會在服務端轉換為UDP,因此建議客戶端使用
UDP來進行傳輸. 至於為什麼要支持TCP,那是因為一部分防火牆會完全阻擋UDP數據,而對於三次握手的TCP數據則不做隔離.
要在伺服器端獲得一個中繼分配,客戶端須使用分配事務. 客戶端發送分配請求(Allocate request)到伺服器,然後伺服器返回分配成功響應,並包含了分配的地址.客戶端可以在屬性欄位描述其想要的分配類型(比如生命周期).由於中繼數據實現了安全傳輸,伺服器會要求對客戶端進行驗證,主要使用STUN的long-term credential mechanism.
一旦中繼傳輸地址分配好,客戶端必須要將其保活.通常的方法是發送刷新請求(Refresh request)到服務端.這在TURN中是一個標準的方法.刷新頻率取決於分配的生命期,默認為10分鍾.客戶端也可以在刷新請求里指定一個更長的生命期,而伺服器會返回一個實際上分配的時間. 當客戶端想中指通信時,可以發送一個生命期為0的刷新請求.
伺服器和客戶端都保存有一個成為五元組(5-TUPLE)的信息,比如對於客戶端來說,五元組包括客戶端本地地址/埠,伺服器地址/埠,和傳輸協議;伺服器也是類似,只不過將客戶端的地址變為其反射地址,因為那才是伺服器所見到的. 伺服器和客戶端在分配
請求中都帶有5-TUPLE信息,並且也在接下來的信息傳輸中使用,因此彼此都知道哪一次分配對應哪一次傳輸.
如上圖所示,客戶端首先發送Allocate請求,但是沒帶驗證信息,因此STUN伺服器會返回error response,客戶端收到錯誤後加上所需的驗證信息再次請求,才能進行成功的分配.
client和peer之間有兩種方法通過TURN server交換應用信息,第一種是使用Send和Data方法(method),第二種是使用通道(channels),兩種方法都通過某種方式告知伺服器哪個peer應該接收數據,以及伺服器告知client數據來自哪個peer.
Send Mechanism使用了Send和Data指令(Indication).其中Send指令用來把數據從client發送到server,而Data指令用來把數據從server發送到client.當使用Send指令時,客戶端發送一個Send Indication到服務端,其中包含:
當伺服器收到Send Indication之後,會將DATA部分的數據解析出來,並將其以UDP的格式轉發到對應的端點去,並且在封裝數據包的時候把client的中繼地址作為源地址.從而從對等端發送到中繼地址的數據也會被伺服器轉發到client上.值得一提的是,Send/Data Indication是不支持驗證的,因為長效驗證機制不支持對indication的驗證,因此為了防止攻擊,TURN要求client在給對等端發送indication之前先安裝一個到對等端的許可(permission),如下圖所示,client到Peer B沒有安裝許可,導致其indication數據包將被伺服器丟棄,對於peer B也是同樣:
TURN支持兩種方式來創建許可,一種是發送CreatePermission request
對於一些應用程序,比如VOIP(Voice over IP),在Send/Data Indication中多加的36位元組格式信息會加重客戶端和服務端之間的帶寬壓力.為改善這種情況,TURN提供了第二種方法來讓client和peer交互數據.該方法使用另一種數據包格式,即ChannelData message,信道數據報文. ChannelData message不使用STUN頭部,而使用一個4位元組的頭部,包含了一個稱之為信道號的值(channel number).每一個使用中的信道號都與一個特定的peer綁定,即作為對等端地址的一個記號.
要將一個信道與對等端綁定,客戶端首先發送一個信道綁定請求(ChannelBind Request)到伺服器,並且指定一個未綁定的信道號以及對等端的地址信息.綁定後client和server都能通過ChannelData message來發送和轉發數據.信道綁定默認持續10分鍾,並且可以通過重新發送ChannelBind Request來刷新持續時間.和Allocation不同的是,並沒有直接刪除綁定的方法,只能等待其超時自動失效.
上圖中0x4001為信道號,即ChannelData message的頭部中頭2位元組,值得一提的是信道號的選取有如下要求:
在上一章也提到過,因為RFC是標准協議,因此實現上往往有良好的兼容性和拓展性.現存的開源P2P應用程序,如果按照標准來設計,可以很容易與之對接.其中比較著名的就是PJSIP,PJSIP是一個開源的多媒體通信庫,實現了許多標准協議,如SIP, SDP, RTP, STUN, TURN 和 ICE. 當然我們也能自己實現.比如GitHub上的TurnServer就是其中一個對TURN服務端的實現.下面在區域網環境下對TURN數據包進行簡要分析.首先有如下機器情況:
這里使用wireshark來抓包分析,首先TurnClient發送Allocation請求:
可以看到第一次requst被伺服器拒絕,因為後者要求nonce驗證信息,伺服器的返回中包含了nonce信息,除此之外還包含了ERROR-CODE,SOFTWARE,FINGERPRINT屬性.
在下一次request請求中,客戶端加上了收到的nonce,以及USERNAME和REALM等屬性,再次發送到TurnServer:
伺服器如果通過驗證,就會返回success response,隨後Client可以通過上文說到的兩種方法與Peer進行通訊,比如下面的Send indication方法:
『拾』 WEBRTC基本概念
AIMD英文全稱：Additive Increase Multiplicative Decrease。TCP/IP模型中，屬於[運輸層]，為了解決[擁塞控制]的一個方法，即：加性增，乘性減，或者叫做「和式增加，積式減少」。
aimd controller是TCP底層的碼率調節概念，但是WebRTC並沒有完全照搬TCP的機制，而是設計了套自己的演算法。
如果處於Incr狀態，增加碼率的方式分為兩種：一種是通信會話剛剛開始，相當於TCP慢啟動，它會進行一個倍數增加，當前使用的碼率乘以系數，系數是1.08；如果是持續在通信狀態，其增加的碼率值是當前碼率在一個RTT時間周期所能傳輸的數據速率。
如果處於Decrease狀態，遞減原則是:過去500ms時間窗內的最大acked bitrate乘上系數0.85,acked bitrate通過feedback反饋過來的報文序號查找本地發送列表就可以得到。
aimd根據上面的規則最終計算到的碼率就是基於延遲擁塞評估到的bwe bitrate碼率。
WebRTC在發送端收到來自接收端的RTCP RR報文，根據其Report Block中攜帶的丟包率信息，動態調整發送端碼率As。
基於延遲的碼率控制運行在接收端，WebRTC根據數據包到達的時間延遲，通過到達時間濾波器，估算出網路延遲m(t)，然後經過過載檢測器判斷當前網路的擁塞狀況，最後在碼率控制器根據規則計算出遠端估計最大碼率Ar。然後，通過RTCP REMB報文返回Ar等到發送端。
發送端綜合As、Ar和預配置的上下限，計算出最終的目標碼率A，該碼率會作用到Encoder、RTP和PacedSender等模塊，控制發送端的碼率。
GCC演算法充分考慮丟包率和延遲對碼率的影響，在實時通訊應用(如視頻會議)中能夠發揮良好效果。然而，在某些特定應用場景下(比如實時在線編輯)，GCC演算法的表現不太讓人滿意，主要體現在它應對峰值流量的能力上，具體表現在：
1）演算法一開始基於Increase狀態增加碼率，當檢測到Decrease狀態時調用Ar[t(i)] = Alpha * Rr[t(i)]，這個時候實時碼率Rr(ti)可能遠小於Ar[t(i-1)]，這樣在後續過程中Ar處於較低水平；此時若有視頻關鍵幀沖擊，則數據包大量在PacedSender的隊列中排隊，造成較大排隊延遲。
2）基於1）中論述的情況，碼率估計模塊反饋給Codec的編碼碼率很低，但編碼器需要編碼關鍵幀時，內部的碼率控制模塊控制出的最小碼率仍然大於反饋碼率。這兩種情況都會造成較大的發送端排隊延遲，進而在接收端造成較大的JitterBuffer延遲，最終導致端到端延遲到達500ms的水平，這在實時在線編輯應用中是無法容忍的。
基於此，Google官方從WebRTC M55開始引入新的碼率估計演算法，把所有碼率計算模塊都移動到發送端，並採用全新的Trendline濾波器，基於碼率探測機制快速准確地估計出實時碼率。
WebRTC在評估延遲差的時候不是對每個包進行估算，而是採用了包組間進行延遲評估，這符合視頻傳輸（視頻幀是需要切分成多個UDP包）的特點，也減少了頻繁計算帶來的誤差。那麼什麼是包組呢？就是距包組中第一個包的發送時刻t0小於5毫秒發送的所有的包成為一組，第一個超過5毫秒的包作為下一個包組第一個包。