3g移動網路中tcp協議的研究

A. 急!!!tcp/ip網路協議現狀及發展趨勢 注意關鍵詞:現狀、發展趨勢

TCP/IP網路協議是目前來說比較完善的協議了,基於OSI七層模型構建,為未來網路模型提供了參數依據和技術上的借鑒.目前的互聯網絕大多數伺服器和終端均使用TCP/IP協議進行互聯互通.TCP/IP也涵蓋了多領域和多個桌面系統.而TCP/IP協議需要針對不同的網路進行不同的設置，且每個節點一般需要一個「IP地址」、一個「子網掩碼」、一個「默認網關」。不過，可以通過動態主機配置協議（DHCP），給客戶端自動分配一個IP地址，避免了出錯，也簡化了TCP/IP協議的設置。 而IP地址的分配和計算出現了以下的情況：現有的互聯網是在IPv4協議的基礎上運行的。IPv6是下一版本的互聯網協議，也可以說是下一代互聯網的協議，它的提出最初是因為隨著互聯網的迅速發展，IPv4定義的有限地址空間將被耗盡，而地址空間的不足必將妨礙互聯網的進一步發展。為了擴大地址空間，擬通過IPv6以重新定義地址空間。IPv4採用32位地址長度，只有大約43億個地址，估計在2005～2010年間將被分配完畢，而IPv6採用128位地址長度，幾乎可以不受限制地提供地址。按保守方法估算IPv6實際可分配的地址，整個地球的每平方米面積上仍可分配1000多個地址。在IPv6的設計過程中除解決了地址短缺問題以外，還考慮了在IPv4中解決不好的其它一些問題，主要有端到端IP連接、服務質量（QoS）、安全性、多播、移動性、即插即用等。
與IPv4相比，IPv6主要有如下一些優勢。第一，明顯地擴大了地址空間。IPv6採用128位地址長度，幾乎可以不受限制地提供IP地址，從而確保了端到端連接的可能性。第二，提高了網路的整體吞吐量。由於IPv6的數據包可以遠遠超過64k位元組，應用程序可以利用最大傳輸單元（MTU），獲得更快、更可靠的數據傳輸，同時在設計上改進了選路結構，採用簡化的報頭定長結構和更合理的分段方法，使路由器加快數據包處理速度，提高了轉發效率，從而提高網路的整體吞吐量。第三，使得整個服務質量得到很大改善。報頭中的業務級別和流標記通過路由器的配置可以實現優先順序控制和QoS保障，從而極大改善了IPv6的服務質量。第四，安全性有了更好的保證。採用IPSec可以為上層協議和應用提供有效的端到端安全保證，能提高在路由器水平上的安全性。第五，支持即插即用和移動性。設備接入網路時通過自動配置可自動獲取IP地址和必要的參數，實現即插即用，簡化了網路管理，易於支持移動節點。而且IPv6不僅從IPv4中借鑒了許多概念和術語，它還定義了許多移動IPv6所需的新功能。第六，更好地實現了多播功能。在IPv6的多播功能中增加了「范圍」和「標志」，限定了路由范圍和可以區分永久性與臨時性地址，更有利於多播功能的實現。
目前，隨著互聯網的飛速發展和互聯網用戶對服務水平要求的不斷提高，IPv6在全球將會越來越受到重視。

B. 什麼是「TCP/IP協議」TCP和IP各有什麼作用

TCP/IP（Transmission Control Protocol/Internet Protocol，傳輸控制協議／網際協議）是指能夠在多個不同網路間實現信息傳輸的協議簇。

TCP/IP協議不僅僅指的是TCP和IP兩個協議，而是指一個由FTP、SMTP、TCP、UDP、IP等協議構成的協議簇，只是因為在TCP/IP協議中TCP協議和IP協議最具代表性，所以被稱為TCP/IP協議。

TCP作用：當應用層向TCP層發送用於網間傳輸的、用8位位元組表示的數據流，TCP則把數據流分割成適當長度的報文段，最大傳輸段大小（MSS）通常受該計算機連接的網路的數據鏈路層的最大傳送單元（MTU）限制。之後TCP把數據包傳給IP層，由它來通過網路將包傳送給接收端實體的TCP層。

IP作用：IP信息包的傳送。P信息包的分割與重組。

TCP/IP協議缺陷

（1）該模型沒有明顯地區分服務、介面和協議的概念。因此，對於使用新技術來設計新網路，TCP/IP模型不是一個太好的模板。

（2）TCP/IP模型完全不是通用的，並且不適合描述除TCP/IP模型之外的任何協議棧。

（3）鏈路層並不是通常意義上的一層。它是一個介面，處於網路層和數據鏈路層之間。介面和層間的區別是很重要的。

以上內容參考網路-IP

以上內容參考網路-TCP

以上內容參考網路-TCP/IP協議

C. 談計算機網路TCP協議的模擬與實現

談計算機網路TCP協議的模擬與實現

TCP是計算機網路中運輸層協議，連接著應用層和網路層，發揮著非常關鍵的作用。那麼，計算機網路TCP協議的模擬與實現是?

作為計算機網路中較為重要的一種運輸層協議，TCP連接著應用層和網路層，發揮著非常關鍵的作用。在TCP/IP協議中，我們重點關注TCP。本文主要立足於TCP協議的特點，詳細介紹了TCP協議的主要特性。

一、TCP協議的概述

(一) TCP協議的特點

首先，TCP提供的連接服務穩定性有保證。相關的連接有著和打電弧相似的建立過程。先撥電話號碼，當對方接通回復“喂”的時候，再告知對方自己是誰，完成任務後釋放;其次，TCP提供連接必須是只針對兩個客戶端，也就是實現一對一的傳輸;最後，TCP提供全雙工通信。這個特點就是保證通信的兩端在使用TCP的時候可以隨時通信，這樣就可以及時傳輸數據。

(二) TCP埠號和套接字地址

TCP埠號：埠號只能對計算機中的進程進行標記，一般使用兩個位元組來完成標記工作，這也就是埠號的本地意義。當埠號並不是我們熟悉的狀況時，要使用數值為1024～49151的等記埠號，使用的過程中要在UANA上登記，避免中間重復使用。無連接的UDP和TCP也有著自己的埠號，但是兩個埠號彼此之間是相互獨立的，各自有著不同的用途。套接字地址：CP中的套接字，一般在表達的過程中會用同一個名詞表達不一樣的含義。也就是說，當套接字被一個程序使用，那麼socket函數中使用的函數以及調用它的埠都會叫做scocket。當緊急URG給系統發出有關緊急數據傳輸的通知時，相關的緊急數據應該作為優先順序任務，盡快被傳送。

二、 TCP的連接與釋放

(一)建立連接

全雙工是TCP傳輸數據的主要方式，在整個過程中有三次握手的方式來完成對該項目的建立，並且TCP的連接和釋放都是使用客戶—伺服器方式，連接的建立也是從伺服器開始。首先將SYN設置為1，然後將數據包頭部的那個確認欄位設置為x+1，接下來將最開始的序列號放在數據包頭部的數列中。當這個鏈接的數據段被接受之後，那麼相應的數據段就會被送到緩沖區，同時，伺服器也能夠及時收到客戶端從另外一邊發來的數據段，最後完成相關輸出的確認。

(二) TCP的連接釋放

TCP傳輸數據的'主要方式是全雙工，因此，數據傳輸結束後，所有的連接都會被釋放，並且每個連接的釋放都是單個放行的。首先，當被A發送的數據能夠到達B，為了杜絕失效的報文段在文本中存在，最後一個一個ACK被發送完後，相關的環節就會處理。這種辦法就能夠及時高效地處理掉連接過程中請求報文段的問題。

(三) TCP的連接復位

一般情況下，有三種情況需要復位。首先，當TCP連接的埠並不存在時，另一端TCP就能發送一個報文段，這時需要關閉相關的連接;其次，如果一端的TCP出現一些異常情況，那麼就可以通過發送復位來終止連接;最後一種情況是，當一端的TCP長時間沒有使用，那麼就可以發送復位信息報，將其關閉。

(四) TCP擁塞控制

TCP的擁塞控制是TCP工作中存在的一種現實問題，會對整個工作造成一定程度的影響，因此，必須針對這種情況進行改進。首先，慢啟動和擁塞避免。TCP用來發送數據是慢啟動和擁塞避免演算法展開的依據，這種演算法的實現必須通過在TCP中增加兩個變數;其次，快恢復和快重傳。這種主要是針對發送端展開的，多種網路會導致埠查收到重復ACK，因此，應該找到事故原因，及時處理。

三、TCP的模擬實驗

(一)模擬實驗的設置

我們都知道TCP是有鏈接的可靠的傳輸層協議，所以在傳輸運用過程中也會出現錯誤。下面我們通過以下模擬實驗，來了解TCP在傳輸FTP文件時一數據報丟失的情況，來詳細分析下這一解決過程。

我們用OPNET來做TCP的模擬實驗，這只是在一個比較簡單的環境下在做關於TCP的模擬實驗，測試出數據圖通過分析和比較來觀察TCP處理數據丟失包的具體工作原理和過程。選擇“結果- - > >安排Pannels顯示所有“查看保存結果。

頂部多媒體的快速decovery conquestion窗口由於“TCP雷諾”，在重新傳輸。這個conquestion窗口只是減少了一半，而不是1MSS，從而快速恢復。graphe的底部顯示了發送之間的關系序列號碼和收到seqment ack伺服器上的數量。伺服器故意把一個數據包給丟失，這時客戶伺服器就會發出三個ACK，會被重新發送。

這時把FTP的Command Mix的值設置為100%，把Inter-Requests設置為constant 3600，把File Size設置為FTP，把Server，type of serveice值設置為best effort，把RSVP parameters值設置為 None;用NotUsed來設置Back-End Custom Application值。

(二)模擬實驗的過程

針對TCP數據傳輸開始時，擁塞窗口設置為最大的MSS值，慢啟動演算法開始，cwnd被設置為200，那麼400，800，1600.......以103S，擁塞窗口達到6500的最大閾值，為了不讓擁塞窗口將不會太增加網路阻塞引起的，然後執行擁塞避免演算法，每一個RTT，擁塞窗口將增加一個單位，然後在107s當FTP數據包丟失，然後進行處理，擁塞窗口的值下降，TCP協議在慢啟動和擁塞避免演算法的實現，窗口的大小增長將呈現線性增長。設置最大窗口閾值，根據3響應消息重復判斷丟包，重傳丟失的數據包和直接的閾值，為當前擁塞窗口6500的一半，這是快速重傳(Tahoe)，然後轉移到慢啟動。然後再轉入慢開始。

在窗口大小到達大約80000後，應該是收到3個連續ACK，若根據3個重復的應答報文就會知道有沒有丟包，而且丟失的分組會被重傳，此時的ssthresh的值就為擁塞窗口的一半，這樣就進入了進入擁塞避免階段。

(三)模擬實驗小結

用OPNET做TCP的模擬實驗，數據包丟失，TCP數據的變化都被形象的描繪出來了，很好的詮釋了這一失誤和改正過程。為TCP以後出錯改正做了很好的例子。

四、結語

綜上所述，網路普及的這個時代，讓我們不斷地認識到了計算機網路的重要性，學生們也開始越來越重視對TCP的研究。在簡單的OSI體系中，TCP發揮著較為重要的作用，因此，我們必須深入研究其工作原理，便於在運輸層中順利地運用TCP協議。

;

D. 3G網路遵循什麼通信協議TCP/IP嗎

我暈啊，TCP/IP是網路層協議，適用於互聯網的。
3G的協議有幾種，WCDMA是主流也就是聯通用的，還有CMDA2000電信用的，這些都是外國制定的標准。還有就是移動用的TD-SCDMA這是我國自主制定的標准 很差

E. TCP協議詳解及實戰解析【精心整理收藏】

TCP協議是在TCP/IP協議模型中的運輸層中很重要的一個協議、負責處理主機埠層面之間的數據傳輸。主要有以下特點：

1.TCP是面向鏈接的協議，在數據傳輸之前需要通過三次握手建立TCP鏈接，當數據傳遞完成之後，需要通過四次揮手進行連接釋放。

2.每一條TCP通信都是兩台主機和主機之間的，是點對點傳輸的協議。

3.TCP提供可靠的、無差錯、不丟失、不重復，按序到達的服務。

4.TCP的通信雙方在連接建立的任何時候都可以發送數據。TCP連接的兩端都設有發送緩存和接收緩存，用來臨時存放雙向通信的數據。

5.面向位元組流。在數據傳輸的過程中如果報文比較長的話TCP會進行數據分段傳輸，每一條分段的TCP傳輸信息都帶有分段的序號，每一段都包含一部分位元組流。接收方根據每段攜帶的的序號信息進行數據拼接，最終拼接出來初始的傳輸數據。但是在整個傳輸的過程中每一段TCP攜帶的都是被切割的位元組流數據。所以說TCP是面向位元組流的。

a.TCP和UDP在發送報文時所採用的方式完全不同。TCP並不關心應用程序一次把多長的報文發送到TCP緩存中，而是根據對方給出的窗口值和當前網路擁塞的程度來決定一個報文段應包含多少個位元組（UDP發送的報文長度是應用程序給出的）。
b.如果應用程序傳送到TCP緩存的數據塊太大，TCP就可以把它劃分短一些再傳。TCP也可以等待積累有足夠多的位元組後再構建成報文段發送出去。

各欄位含義：

源埠：發送端的埠號

目的埠：接收端的埠號

序號：TCP將發送報文分段傳輸的時候會給每一段加上序號，接收端也可以根據這個序號來判斷數據拼接的順序，主要用來解決網路報亂序的問題

確認號：確認號為接收端收到數據之後進行排序確認以及發送下一次期待接收到的序號，數值 = 接收到的發送號 + 1

數據偏移：佔4比特，表示數據開始的地方離TCP段的起始處有多遠。實際上就是TCP段首部的長度。由於首部長度不固定，因此數據偏移欄位是必要的。數據偏移以32位為長度單位，因此TCP首部的最大長度是60（15*4）個位元組。

控制位：

URG：此標志表示TCP包的緊急指針域有效，用來保證TCP連接不被中斷，並且督促 中間層設備要盡快處理這些數據;

ACK：此標志表示應答域有效，就是說前面所說的TCP應答號將會包含在TCP數據包中;有兩個取值：0和1， 為1的時候表示應答域有效，反之為0;

PSH：這個標志位表示Push操作。所謂Push操作就是指在數據包到達接收端以後，立即傳送給應用程序， 而不是在緩沖區中排隊;

RST：這個標志表示連接復位請求。用來復位那些產生錯誤的連接，也被用來拒絕錯誤和非法的數據包;

SYN：表示同步序號，用來建立連接。SYN標志位和ACK標志位搭配使用，當連接請求的時候，SYN=1， ACK=0;連接被響應的時候，SYN=1，ACK=1;這個標志的數據包經常被用來進行埠掃描。掃描者發送 一個只有SYN的數據包，如果對方主機響應了一個數據包回來 ，就表明這台主機存在這個埠;但是由於這 種掃描方式只是進行TCP三次握手的第一次握手，因此這種掃描的成功表示被掃描的機器不很安全，一台安全 的主機將會強制要求一個連接嚴格的進行TCP的三次握手;

FIN： 表示發送端已經達到數據末尾，也就是說雙方的數據傳送完成，沒有數據可以傳送了，發送FIN標志 位的TCP數據包後，連接將被斷開。這個標志的數據包也經常被用於進行埠掃描。

窗口：TCP里很重要的一個機制，佔2位元組，表示報文段發送方期望接收的位元組數，可接收的序號范圍是從接收方的確認號開始到確認號加上窗口大小之間的數據。後面會有實例講解。

校驗和：校驗和包含了偽首部、TCP首部和數據，校驗和是TCP強制要求的，由發送方計算，接收方驗證

緊急指針：URG標志為1時，緊急指針有效，表示數據需要優先處理。緊急指針指出在TCP段中的緊急數據的最後一個位元組的序號，使接收方可以知道緊急數據共有多長。

選項：最常用的選項是最大段大小（Maximum Segment Size，MSS），向對方通知本機可以接收的最大TCP段長度。MSS選項只在建立連接的請求中發送。

放在乙太網幀里看TCP的位置

TCP 數據包在 IP 數據包的負載裡面。它的頭信息最少也需要20位元組，因此 TCP 數據包的最大負載是 1480 - 20 = 1460 位元組。由於 IP 和 TCP 協議往往有額外的頭信息，所以 TCP 負載實際為1400位元組左右。

因此，一條1500位元組的信息需要兩個 TCP 數據包。HTTP/2 協議的一大改進， 就是壓縮 HTTP 協議的頭信息，使得一個 HTTP 請求可以放在一個 TCP 數據包裡面，而不是分成多個，這樣就提高了速度。

乙太網數據包的負載是1500位元組，TCP 數據包的負載在1400位元組左右

一個包1400位元組，那麼一次性發送大量數據，就必須分成多個包。比如，一個 10MB 的文件，需要發送7100多個包。

發送的時候，TCP 協議為每個包編號（sequence number，簡稱 SEQ），以便接收的一方按照順序還原。萬一發生丟包，也可以知道丟失的是哪一個包。

第一個包的編號是一個隨機數。為了便於理解，這里就把它稱為1號包。假定這個包的負載長度是100位元組，那麼可以推算出下一個包的編號應該是101。這就是說，每個數據包都可以得到兩個編號：自身的編號，以及下一個包的編號。接收方由此知道，應該按照什麼順序將它們還原成原始文件。

收到 TCP 數據包以後，組裝還原是操作系統完成的。應用程序不會直接處理 TCP 數據包。

對於應用程序來說，不用關心數據通信的細節。除非線路異常，否則收到的總是完整的數據。應用程序需要的數據放在 TCP 數據包裡面，有自己的格式（比如 HTTP 協議）。

TCP 並沒有提供任何機制，表示原始文件的大小，這由應用層的協議來規定。比如，HTTP 協議就有一個頭信息Content-Length，表示信息體的大小。對於操作系統來說，就是持續地接收 TCP 數據包，將它們按照順序組裝好，一個包都不少。

操作系統不會去處理 TCP 數據包裡面的數據。一旦組裝好 TCP 數據包，就把它們轉交給應用程序。TCP 數據包裡面有一個埠（port）參數，就是用來指定轉交給監聽該埠的應用程序。

應用程序收到組裝好的原始數據，以瀏覽器為例，就會根據 HTTP 協議的Content-Length欄位正確讀出一段段的數據。這也意味著，一次 TCP 通信可以包括多個 HTTP 通信。

伺服器發送數據包，當然越快越好，最好一次性全發出去。但是，發得太快，就有可能丟包。帶寬小、路由器過熱、緩存溢出等許多因素都會導致丟包。線路不好的話，發得越快，丟得越多。

最理想的狀態是，在線路允許的情況下，達到最高速率。但是我們怎麼知道，對方線路的理想速率是多少呢？答案就是慢慢試。

TCP 協議為了做到效率與可靠性的統一，設計了一個慢啟動（slow start）機制。開始的時候，發送得較慢，然後根據丟包的情況，調整速率：如果不丟包，就加快發送速度；如果丟包，就降低發送速度。

Linux 內核裡面 設定 了（常量TCP_INIT_CWND），剛開始通信的時候，發送方一次性發送10個數據包，即"發送窗口"的大小為10。然後停下來，等待接收方的確認，再繼續發送。

默認情況下，接收方每收到 兩個 TCP 數據包，就要 發送 一個確認消息。"確認"的英語是 acknowledgement，所以這個確認消息就簡稱 ACK。

ACK 攜帶兩個信息。

發送方有了這兩個信息，再加上自己已經發出的數據包的最新編號，就會推測出接收方大概的接收速度，從而降低或增加發送速率。這被稱為"發送窗口"，這個窗口的大小是可變的。

注意，由於 TCP 通信是雙向的，所以雙方都需要發送 ACK。兩方的窗口大小，很可能是不一樣的。而且 ACK 只是很簡單的幾個欄位，通常與數據合並在一個數據包裡面發送。

即使對於帶寬很大、線路很好的連接，TCP 也總是從10個數據包開始慢慢試，過了一段時間以後，才達到最高的傳輸速率。這就是 TCP 的慢啟動。

TCP 協議可以保證數據通信的完整性，這是怎麼做到的？

前面說過，每一個數據包都帶有下一個數據包的編號。如果下一個數據包沒有收到，那麼 ACK 的編號就不會發生變化。

舉例來說，現在收到了4號包，但是沒有收到5號包。ACK 就會記錄，期待收到5號包。過了一段時間，5號包收到了，那麼下一輪 ACK 會更新編號。如果5號包還是沒收到，但是收到了6號包或7號包，那麼 ACK 裡面的編號不會變化，總是顯示5號包。這會導致大量重復內容的 ACK。

如果發送方發現收到 三個 連續的重復 ACK，或者超時了還沒有收到任何 ACK，就會確認丟包，即5號包遺失了，從而再次發送這個包。通過這種機制，TCP 保證了不會有數據包丟失。

TCP是一個滑動窗口協議，即一個TCP連接的發送端在某個時刻能發多少數據是由滑動窗口控制的，而滑動窗口的大小實際上是由兩個窗口共同決定的，一個是接收端的通告窗口，這個窗口值在TCP協議頭部信息中有，會隨著數據的ACK包發送給發送端，這個值表示的是在接收端的TCP協議緩存中還有多少剩餘空間，發送端必須保證發送的數據不超過這個剩餘空間以免造成緩沖區溢出，這個窗口是接收端用來進行流量限制的，在傳輸過程中，通告窗口大小與接收端的進程取出數據的快慢有關。另一個窗口是發送端的擁塞窗口(Congestion window)，由發送端維護這個值，在協議頭部信息中沒有，滑動窗口的大小就是通告窗口和擁塞窗口的較小值，所以擁塞窗口也看做是發送端用來進行流量控制的窗口。滑動窗口的左邊沿向右移動稱為窗口合攏，發生在發送的數據被確認時（此時，表明數據已被接收端收到，不會再被需要重傳，可以從發送端的發送緩存中清除了），滑動窗口的右邊沿向右移動稱為窗口張開，發生在接收進程從接收端協議緩存中取出數據時。隨著發送端不斷收到的被發送數據的ACK包，根據ACK包中的確認序號和通告窗口大小使滑動窗口得以不斷的合攏和張開，形成滑動窗口的向前滑動。如果接收進程一直不取數據，則會出現0窗口現象，即滑動窗口左邊沿與右邊沿重合，此時窗口大小為0，就無法再發送數據。

在TCP里，接收端(B)會給發送端(A)報一個窗口的大小，叫Advertised window。

1.在沒有收到B的確認情況下，A可以連續把窗口內的數據都發送出去。凡是已經發送過的數據，在

未收到確認之前都必須暫時保留，以便在超時重傳時使用。

2.發送窗口裡面的序號表示允許發送的序號。顯然，窗口越大，發送方就可以在收到對方確認之前連續

發送更多數據，因而可能獲得更高的傳輸效率。但接收方必須來得及處理這些收到的數據。

3.發送窗口後沿的後面部分表示已發送且已收到確認。這些數據顯然不需要再保留了。

4.發送窗口前沿的前面部分表示不允許發送的，應為接收方都沒有為這部分數據保留臨時存放的緩存空間。

5.發送窗口後沿的變化情況有兩種：不動（沒有收到新的確認）和前移（收到了新的確認）

6.發送窗口前沿的變化情況有兩種：不斷向前移或可能不動（沒收到新的確認）

TCP的發送方在規定時間內沒有收到確認就要重傳已發送的報文段。這種重傳的概念很簡單，但重傳時間的選擇確是TCP最復雜的問題之一。TCP採用了一種自適應演算法，它記錄一個報文段發出的時間，以及收到響應的確認的時間

這兩個時間之差就是報文段的往返時間RTT。TCP保留了RTT的一個加權平均往返時間。超時重傳時間RTO略大於加權平均往返時間

RTT：
即Round Trip Time，表示從發送端到接收端的一去一回需要的時間，tcp在數據傳輸過程中會對RTT進行采樣（即對發送的數據包及其ACK的時間差進行測量，並根據測量值更新RTT值，具體的演算法TCPIP詳解裡面有），TCP根據得到的RTT值更新RTO值，即Retransmission TimeOut，就是重傳間隔，發送端對每個發出的數據包進行計時，如果在RTO時間內沒有收到所發出的數據包的對應ACK，則任務數據包丟失，將重傳數據。一般RTO值都比采樣得到的RTT值要大。

如果收到的報文段無差錯，只是未按序號，中間還缺少一些序號的數據，那麼能否設法只傳送缺少的數據而不重傳已經正確到達接收方的數據？

答案是可以的，選擇確認就是一種可行的處理方法。

如果要使用選項確認SACK，那麼在建立TCP連接時，就要在TCP首部的選項中加上「允許SACK」的選項，而雙方必須都事先商定好。如果使用選擇確認，

那麼原來首部中的「確認號欄位」的用法仍然不變。SACK文檔並沒有明確發送方應當怎麼響應SACK.因此大多數的實現還是重傳所有未被確認的數據塊。

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

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

擁塞控制方法：

1.慢開始和擁塞避免

2.快重傳和快恢復

3.隨機早期檢測

1.一開始，客戶端和服務端都處於CLOSED狀態

2.先是服務端主動監聽某個埠，處於LISTEN狀態（比如服務端啟動，開始監聽）。

3.客戶端主動發起連接SYN，之後處於SYN-SENT狀態（第一次握手，發送 SYN = 1 ACK = 0 seq = x ack = 0）。

4.服務端收到發起的連接，返回SYN，並且ACK客戶端的SYN，之後處於SYN-RCVD狀態（第二次握手，發送 SYN = 1 ACK = 1 seq = y ack = x + 1）。

5.客戶端收到服務端發送的SYN和ACK之後，發送ACK的ACK，之後處於ESTABLISHED狀態（第三次握手，發送 SYN = 0 ACK = 1 seq = x + 1 ack = y + 1）。

6.服務端收到客戶端的ACK之後，處於ESTABLISHED狀態。

（需要注意的是，有可能X和Y是相等的，可能都是0，因為他們代表了各自發送報文段的序號。）

TCP連接釋放四次揮手

1.當前A和B都處於ESTAB-LISHED狀態。

2.A的應用進程先向其TCP發出連接釋放報文段，並停止再發送數據，主動關閉TCP連接。

3.B收到連接釋放報文段後即發出確認，然後B進入CLOSE-WAIT(關閉等待)狀態。TCP伺服器進程這時應通知高層應用進程，因而從A到B這個方向的連接就釋放了，這時TCP連接處於半關閉狀態，即A已經沒有數據發送了。

從B到A這個方向的連接並未關閉，這個狀態可能會持續一些時間。

4.A收到來自B的確認後，就進入FIN-WAIT-2(終止等待2)狀態，等待B發出的連接釋放報文端。

5.若B已經沒有向A發送的數據，B發出連接釋放信號，這時B進入LAST-ACK(最後確認)狀態等待A的確認。

6.A再收到B的連接釋放消息後，必須對此發出確認，然後進入TIME-WAIT（時間等待）狀態。請注意，現在TCP連接還沒有釋放掉，必須經過時間等待計時器（TIME－WAIT timer）設置的時間2MSL後，A才進入CLOSED狀態。

7。B收到A發出的確認消息後，進入CLOSED狀態。

以請求網路為例，看一下三次握手真實數據的TCP連接建立過程

我們再來看四次揮手。TCP斷開連接時，會有四次揮手過程，標志位是FIN，我們在封包列表中找到對應位置，理論上應該找到4個數據包，但我試了好幾次，實際只抓到3個數據包。查了相關資料，說是因為伺服器端在給客戶端傳回的過程中，將兩個連續發送的包進行了合並。因此下面會按照合並後的三次揮手解釋，若有錯誤之處請指出。

第一步，當主機A的應用程序通知TCP數據已經發送完畢時，TCP向主機B發送一個帶有FIN附加標記的報文段（FIN表示英文finish）。

第二步，主機B收到這個FIN報文段之後，並不立即用FIN報文段回復主機A，而是先向主機A發送一個確認序號ACK，同時通知自己相應的應用程序：對方要求關閉連接（先發送ACK的目的是為了防止在這段時間內，對方重傳FIN報文段）。

第三步，主機B的應用程序告訴TCP：我要徹底的關閉連接，TCP向主機A送一個FIN報文段。

第四步，主機A收到這個FIN報文段後，向主機B發送一個ACK表示連接徹底釋放。

這是因為服務端在LISTEN狀態下，收到建立連接請求的SYN報文後，把ACK和SYN放在一個報文里發送給客戶端。而關閉連接時，當收到對方的FIN報文時，僅僅表示對方不再發送數據了但是還能接收數據，己方也未必全部數據都發送給對方了，所以己方可以立即close，也可以發送一些數據給對方後，再發送FIN報文給對方來表示同意現在關閉連接，因此，己方ACK和FIN一般都會分開發送。

原因有二：
一、保證TCP協議的全雙工連接能夠可靠關閉
二、保證這次連接的重復數據段從網路中消失

先說第一點，如果Client直接CLOSED了，那麼由於IP協議的不可靠性或者是其它網路原因，導致Server沒有收到Client最後回復的ACK。那麼Server就會在超時之後繼續發送FIN，此時由於Client已經CLOSED了，就找不到與重發的FIN對應的連接，最後Server就會收到RST而不是ACK，Server就會以為是連接錯誤把問題報告給高層。這樣的情況雖然不會造成數據丟失，但是卻導致TCP協議不符合可靠連接的要求。所以，Client不是直接進入CLOSED，而是要保持TIME_WAIT，當再次收到FIN的時候，能夠保證對方收到ACK，最後正確的關閉連接。

再說第二點，如果Client直接CLOSED，然後又再向Server發起一個新連接，我們不能保證這個新連接與剛關閉的連接的埠號是不同的。也就是說有可能新連接和老連接的埠號是相同的。一般來說不會發生什麼問題，但是還是有特殊情況出現：假設新連接和已經關閉的老連接埠號是一樣的，如果前一次連接的某些數據仍然滯留在網路中，這些延遲數據在建立新連接之後才到達Server，由於新連接和老連接的埠號是一樣的，又因為TCP協議判斷不同連接的依據是socket pair，於是，TCP協議就認為那個延遲的數據是屬於新連接的，這樣就和真正的新連接的數據包發生混淆了。所以TCP連接還要在TIME_WAIT狀態等待2倍MSL，這樣可以保證本次連接的所有數據都從網路中消失。

硬體速度
網路和伺服器的負載
請求和響應報文的尺寸
客戶端和伺服器之間的距離
TCP 協議的技術復雜性

TCP 連接建立握手；
TCP 慢啟動擁塞控制；
數據聚集的 Nagle 演算法；
用於捎帶確認的 TCP 延遲確認演算法；
TIME_WAIT 時延和埠耗盡。

介紹完畢，就這？
是的，就這。

補充：

大部分內容為網路整理，方便自己學習回顧，參考文章：
TCP 協議簡介
TCP協議圖文詳解
什麼是TCP協議？
wireshark抓包分析——TCP/IP協議
TCP協議的三次握手和四次揮手
TCP協議詳解
TCP帶寬和時延的研究(1)

F. TCP/IP、SIP協議

TCP/IP協議 （傳輸控制協議/網間協議）

TCP/IP 協議集確立了 Internet 的技術基礎。TCP/IP 的發展始於美國 DOD （國防部）方案。 IAB （Internet 架構委員會）的下屬工作組 IETF （Internet 工程任務組）研發了其中多數協議。 IAB 最初由美國政府發起，如今轉變為公開而自治的機構。IAB 協同研究和開發 TCP/IP 協議集的底層結構，並引導著 Internet 的發展。TCP/IP 協議集記錄在請求註解（RFC）文件中，RFC 文件均由 IETF 委員會起草、討論、傳閱及核准。所有這些文件都是公開且免費的，且能在 IETF 網站上列出的參考文獻中找到。
TCP/IP 協議覆蓋了 OSI 網路結構七層模型中的六層，並支持從交換（第二層）諸如多協議標記交換，到應用程序諸如郵件服務方面的功能。TCP/IP 的核心功能是定址和路由選擇（網路層的 IP/IPV6 ）以及傳輸控制（傳輸層的 TCP、UDP）。

IP （網際協議）

在網路通信中，網路組件的定址對信息的路由選擇和傳輸來說是相當關鍵的。相同網路中的兩台機器間的消息傳輸有各自的技術協定。LAN 是通過提供6位元組的唯一標識符（「MAC」地址）在機器間發送消息的。SNA 網路中的每台機器都有一個邏輯單元及與其相應的網路地址。DECNET、AppleTalk 和 Novell IPX 均有一個用來分配編號到各個本地網和工作站的配置。

除了本地或特定提供商的網路地址，IP 為世界范圍內的各個網路設備都分配了一個唯一編號，即 IP 地址。IPV4 的 IP 地址為4位元組，按照慣例，將每個位元組轉化成十進制（0-255）並以點分隔各位元組。IPV6 的 IP 地址已經增加到16位元組。關於 IP 和 IPV6 協議的詳細說明，在相關文件中再另作介紹。

TCP （傳輸控制協議）

通過序列化應答和必要時重發數據包，TCP 為應用程序提供了可靠的傳輸流和虛擬連接服務。TCP 主要提供數據流轉送，可靠傳輸，有效流控制，全雙工操作和多路傳輸技術。可查閱 TCP 部分獲取更多詳細資料。

在下面的 TCP/IP 協議表格中，我們根據協議功能和其在 OSI 七層網路通信參考模型的映射關系將其全部列出。然而，TCP/IP 並不完全遵循 OSI 模型，例如：大多數 TCP/IP 應用程序是直接在傳輸層協議 TCP 和 UDP 上運行，而不涉及其中的表示層和會話層。

主要協議表

IP TCP UDP IPsec HTTP POP3 SNMP MPLS DNS SMTP

應用層（Application Layer）

--------------------------------------------------------------------------------

BOOTP：引導協議 （BOOTP：Bootstrap Protocol）
DCAP：數據轉接客戶訪問協議 （DCAP：Data Link Switching Client Access Protocol）
DHCP：動態主機配置協議 （DHCP：Dynamic Host Configuration Protocol）
DNS：域名系統（服務）系統 （DNS：Domain Name Systems）
Finger：用戶信息協議 （Finger：User Information Protocol）
FTP：文件傳輸協議 （FTP：File Transfer Protocol）
HTTP：超文本傳輸協議 （HTTP：Hypertext Transfer Protocol）
S-HTTP：安全超文本傳輸協議 （S-HTTP：Secure Hypertext Transfer Protocol）
IMAP & IMAP4：信息訪問協議 & 信息訪問協議第4版 （IMAP & IMAP4：Internet Message Access Protocol）
IPDC：IP 設備控制 （IPDC：IP Device Control）
IRCP/IRC：網際網路在線聊天協議 （IRCP/IRC：Internet Relay Chat Protocol）
LDAP：輕量級目錄訪問協議 （LDAP：Lightweighted Directory Access Protocol）
MIME/S-MIME/Secure MIME：多用途網際郵件擴充協議 （MIME/S-MIME/Secure MIME：Multipurpose Internet Mail Extensions）
NAT：網路地址轉換 （NAT：Network Address Translation）
NNTP：網路新聞傳輸協議 （NNTP：Network News Transfer Protocol）
NTP：網路時間協議 （NTP：Network Time Protocol）
POP&POP3：郵局協議 （POP & POP3：Post Office Protocol）
RLOGIN：遠程登錄命令 （RLOGIN：Remote Login in Unix）
RMON：遠程監控 （RMON：Remote Monitoring MIBs in SNMP）
RWhois：遠程目錄訪問協議 （RWhois Protocol）
SLP：服務定位協議 （SLP：Service Location Protocol）
SMTP：簡單郵件傳輸協議 （SMTP：Simple Mail Transfer Protocol）
SNMP：簡單網路管理協議 （SNMP：Simple Network Management Protocol）
SNTP：簡單網路時間協議 （SNTP：Simple Network Time Protocol）
TELNET：TCP/IP 終端模擬協議 （TELNET：TCP/IP Terminal Emulation Protocol）
TFTP：簡單文件傳輸協議 （TFTP：Trivial File Transfer Protocol）
URL：統一資源管理 （URL：Uniform Resource Locator）
X-Window/X Protocol：X 視窗 或 X 協議（X-Window：X Window or X Protocol or X System）

表示層（Presentation Layer）

--------------------------------------------------------------------------------

LPP：輕量級表示協議 （LPP：Lightweight Presentation Protocol）

會話層（Session Layer）

--------------------------------------------------------------------------------

RPC：遠程過程調用協議 （RPC：Remote Procere Call protocol）

傳輸層（Transport Layer）

--------------------------------------------------------------------------------

ITOT：基於TCP/IP 的 ISO 傳輸協議 （ITOT：ISO Transport Over TCP/IP）
RDP：可靠數據協議 （RDP：Reliable Data Protocol）
RUDP：可靠用戶數據報協議 （RUDP：Reliable UDP）
TALI：傳輸適配層介面 （TALI：Transport Adapter Layer Interface）
TCP：傳輸控制協議 （TCP：Transmission Control Protocol）
UDP：用戶數據報協議 （UDP：User Datagram Protocol）
Van Jacobson：壓縮 TCP 協議 （Van Jacobson：Compressed TCP）

網路層（Network Layer）

--------------------------------------------------------------------------------

路由選擇（Routing）
BGP/BGP4：邊界網關協議 （BGP/BGP4：Border Gateway Protocol）
EGP：外部網關協議（EGP：Exterior Gateway Protocol）
IP：網際協議 （IP：Internet Protocol）
IPv6：網際協議第6版 （IPv6：Internet Protocol version 6）
ICMP/ICMPv6：Internet 信息控制協議 （ICMP/ICMPv6：Internet Control Message Protocol）
IRDP：ICMP 路由器發現協議 （IRDP：ICMP Router Discovery Protocol）
Mobile IP： 移動 IP （Mobile IP：IP Mobility Support Protocol for IPv4 & IPv6）
NARP：NBMA 地址解析協議 （NARP：NBMA Address Resolution Protocol）
NHRP：下一跳解析協議 （NHRP：Next Hop Resolution Protocol）
OSPF：開放最短路徑優先 （OSPF：Open Shortest Path First）
RIP/RIP2：路由選擇信息協議 （RIP/RIP2：Routing Information Protocol）
RIPng：路由選擇信息協議下一代 （RIPng：RIP for IPv6）
RSVP：資源預留協議 （RSVP：Resource ReSerVation Protocol）
VRRP：虛擬路由器冗餘協議 （VRRP：Virtual Router Rendancy Protocol）

組播（Multicast）
BGMP：邊界網關組播協議 （BGMP：Border Gateway Multicast Protocol）
DVMRP：距離矢量組播路由協議 （DVMRP：Distance Vector Multicast Routing Protocol）
IGMP：Internet 組管理協議 （IGMP：Internet Group Management Protocol）
MARS：組播地址解析服務 （MARS：Multicast Address Resolution Server）
MBGP：組播協議邊界網關協議 （MBGP：Multiprotocol BGP）
MOSPF：組播OSPF （MOSPF：Multicast OSPF）
MSDP：組播源發現協議 （MSDP：Multicast Source Discovery Protocol）
MZAP：組播區域范圍公告協議 （MZAP：Multicast Scope Zone Announcement Protocol）
PGM：實際通用組播協議 （PGM：Pragmatic General Multicast Protocol）
PIM-DM：密集模式獨立組播協議 （PIM-DM：Protocol Independent Multicast - Dense Mode）
PIM-SM：稀疏模式獨立組播協議 （PIM-SM：Protocol Independent Multicast - Sparse Mode）

MPLS 協議（MPLS Protocols）
CR-LDP：基於路由受限標簽分發協議 （CR-LDP: Constraint-Based Label Distribution Protocol）
GMPLS：通用多協議標志交換協議 （GMPLS：Generalized Multiprotocol Label Switching）
LDP：標簽分發協議 （LDP：Label Distribution Protocol）
MPLS：多協議標簽交換 （MPLS：Multi-Protocol Label Switching）
RSVP-TE：基於流量工程擴展的資源預留協議 （RSVP-TE：Resource ReSerVation Protocol-Traffic Engineering）

數據鏈路層（Data Link Layer）

--------------------------------------------------------------------------------

ARP and InARP：地址轉換協議和逆向地址轉換協議 （ARP and InARP：Address Resolution Protocol and Inverse ARP）
IPCP and IPv6CP：IP控制協議和IPV6控制協議 （IPCP and IPv6CP：IP Control Protocol and IPv6 Control Protocol）
RARP：反向地址轉換協議 （RARP：Reverse Address Resolution Protocol）
SLIP：串形線路 IP （SLIP：Serial Line IP）

SIP
介紹

新一代的服務

歷史回顧

SIP 的優點：類似 Web 的可擴展開放通信

SIP 會話構成

介紹

通信提供商及其合作夥伴和用戶越來越渴求新一代基於 IP 的服務。現在有了 SIP（會話啟動協議），一解燃眉之急。SIP 是不到十年前在計算機科學實驗室誕生的一個想法。它是第一個適合各種媒體內容而實現多用戶會話的協議，現在已成了 Internet 工程任務組 (IETF) 的規范。

今天，越來越多的運營商、CLEC（競爭本地運營商）和 ITSP（IP 電話服務商）都在提供基於 SIP 的服務，如市話和長途電話技術、在線信息和即時消息、IP Centrex/Hosted PBX、語音簡訊、push-to-talk（按鍵通話）、多媒體會議等等。獨立軟體供應商 (ISV) 正在開發新的開發工具，用來為運營商網路構建基於 SIP 的應用程序以及 SIP 軟體。網路設備供應商 (NEV) 正在開發支持 SIP 信令和服務的硬體。現在，有眾多 IP 電話、用戶代理、網路代理伺服器、VOIP 網關、媒體伺服器和應用伺服器都在使用 SIP。

SIP 從類似的權威協議－－如 Web 超文本傳輸協議 (HTTP) 格式化協議以及簡單郵件傳輸協議 (SMTP) 電子郵件協議－－演變而來並且發展成為一個功能強大的新標准。但是，盡管 SIP 使用自己獨特的用戶代理和伺服器，它並非自成一體地封閉工作。SIP 支持提供融合的多媒體服務，與眾多負責身份驗證、位置信息、語音質量等的現有協議協同工作。

本白皮書對 SIP 及其作用進行了概括性的介紹。它還介紹了 SIP 從實驗室開發到面向市場的過程。本白皮書說明 SIP 提供哪些服務以及正在實施哪些促進發展的方案。它還詳細介紹了 SIP 與各種協議不同的重要特點並說明如何建立 SIP 會話。

返回頁首

新一代的服務

SIP 較為靈活，可擴展，而且是開放的。它激發了 Internet 以及固定和移動 IP 網路推出新一代服務的威力。SIP 能夠在多台 PC 和電話上完成網路消息，模擬 Internet 建立會話。

與存在已久的國際電信聯盟 (ITU) SS7 標准（用於呼叫建立）和 ITU H.323 視頻協議組合標准不同，SIP 獨立工作於底層網路傳輸協議和媒體。它規定一個或多個參與方的終端設備如何能夠建立、修改和中斷連接，而不論是語音、視頻、數據或基於 Web 的內容。

SIP 大大優於現有的一些協議，如將 PSTN 音頻信號轉換為 IP 數據包的媒體網關控制協議 (MGCP)。因為 MGCP 是封閉的純語音標准，所以通過信令功能對其進行增強比較復雜，有時會導致消息被破壞或丟棄，從而妨礙提供商增加新的服務。而使用 SIP，編程人員可以在不影響連接的情況下在消息中增加少量新信息。

例如，SIP 服務提供商可以建立包含語音、視頻和聊天內容的全新媒體。如果使用 MGCP、H.323 或 SS7 標准，則提供商必須等待可以支持這種新媒體的協議新版本。而如果使用 SIP，盡管網關和設備可能無法識別該媒體，但在兩個大陸上設有分支機構的公司可以實現媒體傳輸。

而且，因為 SIP 的消息構建方式類似於 HTTP，開發人員能夠更加方便便捷地使用通用的編程語言（如 Java）來創建應用程序。對於等待了數年希望使用 SS7 和高級智能網路 (AIN) 部署呼叫等待、主叫號碼識別以及其他服務的運營商，現在如果使用 SIP，只需數月時間即可實現高級通信服務的部署。

這種可擴展性已經在越來越多基於 SIP 的服務中取得重大成功。Vonage 是針對用戶和小企業用戶的服務提供商。它使用 SIP 向用戶提供 20,000 多條數字市話、長話及語音郵件線路。Deltathree 為服務提供商提供 Internet 電話技術產品、服務和基礎設施。它提供了基於 SIP 的 PC 至電話解決方案，使 PC 用戶能夠呼叫全球任何一部電話。Denwa Communications 在全球范圍內批發語音服務。它使用 SIP 提供 PC 至 PC 及電話至 PC 的主叫號碼識別、語音郵件，以及電話會議、統一通信、客戶管理、自配置和基於 Web 的個性化服務。

某些權威人士預計，SIP 與 IP 的關系將發展成為類似 SMTP 和 HTTP 與 Internet 的關系，但也有人說它可能標志著 AIN 的終結。迄今為止，3G 界已經選擇 SIP 作為下一代移動網路的會話控制機制。Microsoft 已經選擇 SIP 作為其實時通信策略並在 Microsoft XP、Pocket PC 和 MSN Messenger 中進行了部署。Microsoft 同時宣布 CE.net 的下一個版本將使用基於 SIP 的 VoIP 應用介面層，並承諾向用戶 PC 提供基於 SIP 的語音和視頻呼叫。

另外，MCI 正在使用 SIP 向 IP 通信用戶部署高級電話技術服務。用戶將能夠通知主叫方自己是否有空以及首選的通信方式，如電子郵件、電話或即時消息。利用在線信息，用戶還能夠即時建立聊天會話和召開音頻會議。使用 SIP 將不斷地實現各種功能。

返回頁首

歷史回顧

SIP 出現於二十世紀九十年代中期，源於哥倫比亞大學計算機系副教授 Henning Schulzrinne 及其研究小組的研究。Schulzrinne 教授除與人共同提出通過 Internet 傳輸實時數據的實時傳輸協議 (RTP) 外，還與人合作編寫了實時流傳輸協議 (RTSP) 標准提案，用於控制音頻視頻內容在 Web 上的流傳輸。

Schulzrinne 本來打算編寫多方多媒體會話控制 (MMUSIC) 標准。1996 年，他向 IETF 提交了一個草案，其中包含了 SIP 的重要內容。1999 年，Shulzrinne 在提交的新標准中刪除了有關媒體內容方面的無關內容。隨後，IETF 發布了第一個 SIP 規范，即 RFC 2543。雖然一些供應商表示了擔憂，認為 H.323 和 MGCP 協議可能會大大危及他們在 SIP 服務方面的投資，IETF 繼續進行這項工作，於 2001 年發布了 SIP 規范 RFC 3261。

RFC 3261 的發布標志著 SIP 的基礎已經確立。從那時起，已發布了幾個 RFC 增補版本，充實了安全性和身份驗證等領域的內容。例如，RFC 3262 對臨時響應的可靠性作了規定。RFC 3263 確立了 SIP 代理伺服器的定位規則。RFC 3264 提供了提議/應答模型，RFC 3265 確定了具體的事件通知。

早在 2001 年，供應商就已開始推出基於 SIP 的服務。今天，人們對該協議的熱情不斷高漲。Sun Microsystems 的 Java Community Process 等組織正在使用通用的 Java 編程語言定義應用編程介面 (API)，以便開發商能夠為服務提供商和企業構建 SIP 組件和應用程序。最重要的是，越來越多的競爭者正在藉助前途光明的新服務進入 SIP 市場。SIP 正在成為自 HTTP 和 SMTP 以來最為重要的協議之一。

返回頁首

SIP 的優點：類似 Web 的可擴展開放通信

使用 SIP，服務提供商可以隨意選擇標准組件，快速駕馭新技術。不論媒體內容和參與方數量，用戶都可以查找和聯系對方。SIP 對會話進行協商，以便所有參與方都能夠就會話功能達成一致以及進行修改。它甚至可以添加、刪除或轉移用戶。

不過，SIP

不是萬能的。它既不是會話描述協議，也不提供會議控制功能。為了描述消息內容的負載情況和特點，SIP 使用 Internet 的會話描述協議 (SDP) 來描述終端設備的特點。SIP 自身也不提供服務質量 (QoS)，它與負責語音質量的資源保留設置協議 (RSVP) 互操作。它還與若干個其他協議進行協作，包括負責定位的輕型目錄訪問協議 (LDAP)、負責身份驗證的遠程身份驗證撥入用戶服務 (RADIUS) 以及負責實時傳輸的 RTP 等多個協議。

SIP 規定了以下基本的通信要求：

1. 用戶定位服務

2. 會話建立

3. 會話參與方管理

4. 特點的有限確定

SIP 的一個重要特點是它不定義要建立的會話的類型，而只定義應該如何管理會話。有了這種靈活性，也就意味著 SIP 可以用於眾多應用和服務中，包括互動式游戲、音樂和視頻點播以及語音、視頻和 Web 會議。

下面是 SIP 在新的信令協議中出類拔萃的一些其他特點

SIP 消息是基於文本的，因而易於讀取和調試。新服務的編程更加簡單，對於設計人員而言更加直觀。

SIP 如同電子郵件客戶機一樣重用 MIME 類型描述，因此與會話相關的應用程序可以自動啟動。

SIP 重用幾個現有的比較成熟的 Internet 服務和協議，如 DNS、RTP、RSVP 等。不必再引入新服務對 SIP 基礎設施提供支持，因為該基礎設施很多部分已經到位或現成可用。

對 SIP 的擴充易於定義，可由服務提供商在新的應用中添加，不會損壞網路。網路中基於 SIP 的舊設備不會妨礙基於 SIP 的新服務。例如，如果舊 SIP 實施不支持新的 SIP 應用所用的方法/標頭，則會將其忽略。

SIP 獨立於傳輸層。因此，底層傳輸可以是採用 ATM 的 IP。SIP 使用用戶數據報協議 (UDP) 以及傳輸控制協議 (TCP)，將獨立於底層基礎設施的用戶靈活地連接起來。

SIP 支持多設備功能調整和協商。如果服務或會話啟動了視頻和語音，則仍然可以將語音傳輸到不支持視頻的設備，也可以使用其他設備功能，如單向視頻流傳輸功能。

返回頁首

SIP 會話構成

SIP 會話使用多達四個主要組件：SIP 用戶代理、SIP 注冊伺服器、SIP 代理伺服器和 SIP 重定向伺服器。這些系統通過傳輸包括了 SDP 協議（用於定義消息的內容和特點）的消息來完成 SIP 會話。下面概括性地介紹各個 SIP 組件及其在此過程中的作用。

SIP 用戶代理 (UA) 是終端用戶設備，如用於創建和管理 SIP 會話的行動電話、多媒體手持設備、PC、PDA 等。用戶代理客戶機發出消息。用戶代理伺服器對消息進行響應。

SIP 注冊伺服器是包含域中所有用戶代理的位置的資料庫。在 SIP 通信中，這些伺服器會檢索參與方的 IP 地址和其他相關信息，並將其發送到 SIP 代理伺服器。

SIP 代理伺服器接受 SIP UA 的會話請求並查詢 SIP 注冊伺服器，獲取收件方 UA 的地址信息。然後，它將會話邀請信息直接轉發給收件方 UA（如果它位於同一域中）或代理伺服器（如果 UA 位於另一域中）。

SIP 重定向伺服器允許 SIP 代理伺服器將 SIP 會話邀請信息定向到外部域。SIP 重定向伺服器可以與 SIP 注冊伺服器和 SIP 代理伺服器同在一個硬體上。

以下幾個情景說明 SIP 組件之間如何進行協調以在同一域和不同域中的 UA 之間建立 SIP 會話：

在同一域中建立 SIP 會話

下圖說明了在預訂同一個 ISP 從而使用同一域的兩個用戶之間建立 SIP 會話的過程。用戶 A 使用 SIP 電話。用戶 B 有一台 PC，運行支持語音和視頻的軟客戶程序。加電後，兩個用戶都在 ISP 網路中的 SIP 代理伺服器上注冊了他們的空閑情況和 IP 地址。用戶 A 發起此呼叫，告訴 SIP 代理伺服器要聯系用戶 B。然後，SIP 代理伺服器向 SIP 注冊伺服器發出請求，要求提供用戶 B 的 IP 地址，並收到用戶 B 的 IP 地址。SIP 代理伺服器轉發用戶 A 與用戶 B 進行通信的邀請信息（使用 SDP），包括用戶 A 要使用的媒體。用戶 B 通知 SIP 代理伺服器可以接受用戶 A 的邀請，且已做好接收消息的准備。SIP 代理伺服器將此消息傳達給用戶 A，從而建立 SIP 會話。然後，用戶創建一個點到點 RTP 連接，實現用戶間的交互通信。

1.呼叫用戶 B

2.查詢捻沒?B 在哪裡？?br> 3.響應捻沒?B 的 SIP 地址?br> 4.摯�頂呼叫

5. 響應

6. 響應

7. 多媒體通道已建立

返回頁首

在不同的域中建立 SIP 會話

本情景與第一種情景的不同之處如下。用戶 A 邀請正在使用多媒體手持設備的用戶 B 進行 SIP 會話時，域 A 中的 SIP 代理伺服器辨別出用戶 B 不在同一域中。然後，SIP 代理伺服器在 SIP 重定向伺服器上查詢用戶 B 的 IP 地址。SIP 重定向伺服器既可在域 A 中，也可在域 B 中，也可既在域 A 中又在域 B 中。SIP 重定向伺服器將用戶 B 的聯系信息反饋給 SIP 代理伺服器，該伺服器再將 SIP 會話邀請信息轉發給域 B 中的 SIP 代理伺服器。域 B 中的 SIP 代理伺服器將用戶 A 的邀請信息發送給用戶 B。用戶 B 再沿邀請信息經由的同一路徑轉發接受邀請的信息。

1. 呼叫用戶 B 2. 詢問撐胰綰謂油ㄓ?B 中的用戶 B？? 3. 響應摯�碸刂破韉撓虻刂窋 4. 摯�頂呼叫域 B 的 SIP 代理 5. 查詢捻沒?B 在哪裡？? 6. 用戶 B 的地址 7. 代理呼叫 8. 響應 9. 響應 10.響應 11.多媒體通道已建立

無縫、靈活、可擴展：展望 SIP 未來

SIP 能夠連接使用任何 IP 網路（有線 LAN 和 WAN、公共 Internet 骨幹網、移動 2.5G、3G 和 Wi-Fi）和任何 IP 設備（電話、PC、PDA、移動手持設備）的用戶，從而出現了眾多利潤豐厚的新商機，改進了企業和用戶的通信方式。基於 SIP 的應用（如 VOIP、多媒體會議、push-to-talk（按鍵通話）、定位服務、在線信息和 IM）即使單獨使用，也會為服務提供商、ISV、網路設備供應商和開發商提供許多新的商機。不過，SIP 的根本價值在於它能夠將這些功能組合起來，形成各種更大規模的無縫通信服務。

使用 SIP，服務提供商及其合作夥伴可以定製和提供基於 SIP 的組合服務，使用戶可以在單個通信會話中使用會議、Web 控制、在線信息、IM 等服務。實際上，服務提供商可以創建一個滿足多個最終用戶需求的靈活應用程序組合，而不是安裝和支持依賴於終端設備有限特定功能或類型的單一分散的應用程序。

通過在單一、開放的標准 SIP 應用架構下合並基於 IP 的通信服務，服務提供商可以大大降低為用戶設計和部署基於 IP 的新的創新性託管服務的成本。它是 SIP 可擴展性促進本行業和市場發展的強大動力，是我們所有人的希望所在。

G. TCP協議解析

主要特點：面向連接、面向位元組流、全雙工通信、通信可靠。

優缺點：

應用場景：要求通信數據可靠時，即 數據要准確無誤地傳遞給對方。如：傳輸文件：HTTP、HTTPS、FTP等協議；傳輸郵件：POP、SMTP等協議

ps：首部的前 20 個位元組固定，後面有 4n 位元組根據需要增加。故 TCP首部最小長度 = 20位元組（最大60個位元組）。

TCP報頭中的源埠號和目的埠號同IP數據報中的源IP與目的IP唯一確定一條TCP連接。

重要欄位：

客戶端與伺服器來回共發送三個TCP報文段來建立運輸連接，三個TCP報文段分別為：
（1）客戶端A向伺服器B發送的TCP請求報段「SYN=1,seq=x」；
（2）伺服器B向客戶端A發送的TCP確認報文段「SYN=1,ACK=1,seq=y,ack=x+1」；
（3）客戶端A向伺服器B發送的TCP確認報文段「ACK=1,seq=x+1,ack=y+1」。

ps：在建立TCP連接之前，客戶端和伺服器都處於關閉狀態（CLOSED）,直到客戶端主動打開連接，伺服器才被動打開連接（處於監聽狀態 = LISTEN）,等待客戶端的請求。

TCP 協議是一個面向連接的、安全可靠的傳輸層協議，三次握手的機制是為了保證能建立一個安全可靠的連接。

通過上述三次握手， 雙方確認自己與對方的發送與接收是正常的，就建立起一條TCP連接，即可傳送應用層數據 。ps：因 TCP提供的是全雙工通信，故通信雙方的應用進程在任何時候都能發送數據；三次握手期間，任何1次未收到對面的回復，則都會重發。

為什麼兩次握手不行呢 ？

結論：防止伺服器接收了 早已經失效的連接請求報文 ，伺服器同意連接，從而一直等待客戶端請求， 最終導致形成死鎖、浪費資源 。

ps：SYN洪泛攻擊：（具體見下文）

為什麼不需要四次握手呢 ？

SYN 同步序列編號(Synchronize Sequence Numbers) 是 TCP/IP 建立連接時使用的握手信號。在客戶機和伺服器之間建立正常的 TCP 網路連接時，客戶機首先發出一個 SYN 消息，伺服器使用 SYN-ACK 應答表示接收到了這個消息，最後客戶機再以 ACK確認序號標志消息響應。這樣在客戶機和伺服器之間才能建立起可靠的 TCP 連接，數據才可以在客戶機和伺服器之間傳遞。

如何來解決半連接攻擊？

如何來解決全連接攻擊？

請注意 ，現在 TCP 連接還沒有釋放掉。必須經過 時間等待計時器 設置的時間 2MSL（MSL：最長報文段壽命）後，客戶端才能進入到 CLOSED 狀態，然後撤銷傳輸控制塊，結束這次 TCP 連接。當然如果伺服器一收到 客戶端的確認就進入 CLOSED 狀態，然後撤銷傳輸控制塊。所以在釋放連接時，伺服器結束 TCP 連接的時間要早於客戶端。

TCP是全雙工的連接，必須兩端同時關閉連接，連接才算真正關閉。 簡言之，客戶端發送了 FIN 連接釋放報文之後，伺服器收到了這個報文，就進入了 CLOSE-WAIT 狀態。這個狀態是為了讓伺服器端發送還未傳送完畢的數據，傳送完畢之後，伺服器才會發送 FIN 連接釋放報文，對方確認後就完全關閉了TCP連接。

舉個例子：A 和 B 打電話，通話即將結束後，A 說「我沒啥要說的了」，B回答「我知道了」，但是 B 可能還會有要說的話，A 不能要求 B 跟著自己的節奏結束通話，於是 B 可能又巴拉巴拉說了一通，最後 B 說「我說完了」，A 回答「知道了」，這樣通話才算結束。

ps：設想這樣一個情景： 客戶端已主動與伺服器建立了 TCP 連接。但後來客戶端的主機突然發生故障。 顯然，伺服器以後就不能再收到客戶端發來的數據。因此，應當有措施使伺服器不要再白白等待下去。這就需要使用 TCP的保活計時器 。基本原理：

tcp11種狀態及變遷其實基本包含在正常的三次握手和四次揮手中，除開CLOSING。

正常的三次握手包括4中狀態變遷：

伺服器打開監聽(LISTEN)->客戶端先發起SYN主動連接標識->伺服器回復SYN及ACK確認->客戶端再確認即三次握手TCP連接成功。這里邊涉及四種狀態及變遷：

正常的四次握手包含6種tcp狀態變遷，如主動發起關閉方為客戶端：

客戶端發送FIN進入FIN_WAIT1 -> 伺服器發送ACK確認並進入CLOSE_WAIT(被動關閉)狀態->客戶端收到ACK確認後進入FIN_WAIT2狀態 -> 伺服器再發送FIN進入LAST_ACK狀態 -> 客戶端收到伺服器的FIN後發送ACK確認進入TIME_WAIT狀態 -> 伺服器收到ACK確認後進入CLOSED狀態斷開連接 -> 客戶端在等待2MSL的時間如果期間沒有收到伺服器的相關包，則進入CLOSED狀態斷開連接。

CLOSING狀態 ：連接斷開期間，一般是客戶端發送一個FIN，然後伺服器回復一個ACK，然後伺服器發送完數據後再回復一個FIN，當客戶端和伺服器同時接受到FIN時，客戶端和伺服器處於CLOSING狀態，也就是此時雙方都正在關閉同一個連接。

在進入CLOSING狀態後，只要收到了對方對自己發送的FIN的ACK，收到FIN的ACK確認就進入TIME_WAIT狀態，因此，如果RTT(Round Trip Time TCP包的往返延時)處在一個可接受的范圍內，發出的FIN會很快被ACK從而進入到TIME_WAIT狀態，CLOSING狀態持續的時間就特別短，因此很難看到這種狀態。

我們知道網路層，可以實現兩個主機之間的通信。但是這並不具體，因為，真正進行通信的實體是在主機中的進程，是一個主機中的一個進程與另外一個主機中的一個進程在交換數據。IP協議雖然能把數據報文送到目的主機， 但是並沒有交付給主機的具體應用進程 。而 端到端的通信才應該是應用進程之間的通信 。

應用場景 ：UDP協議比TCP協議的效率更高，TCP協議比UDP協議更加安全可靠。

下面主要對 數據傳輸出現錯誤/無應答/堵塞/超時/重復 等問題。

注意：TCP丟包：TCP是基於不可靠的網路實現可靠傳輸，肯定會存在丟包問題。如果在通信過程中，發現缺少數據或者丟包，那邊么 最大的可能性是程序發送過程或者接受過程中出現問題。

總結：為了滿足TCP協議不丟包，即保證可靠傳輸，規定如下：

注意：TCP丟包有三方面的原因，一是網路的傳輸質量不好，二是安全策略，三是伺服器性能瓶頸

先理解2個基礎概念：發送窗口、接收窗口

工作原理：

注意點：

關於滑動窗口的知識點：

滑動窗口中的數據類型：

ARQ解決的問題：出現差錯時，讓發送方重傳差錯數據：即 出錯重傳

類型：

流量控制和擁塞控制解決的問題：當接收方來不及接收收到的數據時，可通知發送方降低發送數據的效率：即 速度匹配

流量控制 ：

注意：

擁塞控制 ：

慢開始與擁塞避免 ：

快重傳和快恢復 ：

補充：流量控制和擁塞控制的區別

什麼情況造成TCP粘包和拆包？

解決TCP粘包和拆包的方法：

傳輸層無法保證數據的可靠傳輸 ，只能通過應用層來實現了。實現的方式可以參照tcp可靠性傳輸的方式，只是實現不在傳輸層，實現轉移到了應用層。

最簡單的方式是在應用層模仿傳輸層TCP的可靠性傳輸。 下面不考慮擁塞處理，可靠UDP的簡單設計。

https://www.jianshu.com/p/65605622234b
http://www.open-open.com/lib/view/open1517213611158.html
https://blog.csdn.net/dangzhangjing97/article/details/81008836
https://blog.csdn.net/qq_30108237/article/details/107057946
https://www.jianshu.com/p/6c73a4585eba