URL訪問網站時的網路傳輸全過程，歸納起來就是：

首先要通過域名找到IP，如果快取裡沒有就要請求DNS伺服器；得到IP後開始於目的主機進行三次握手來建立TCP連線；連線建立後進行HTTP訪問，傳輸並獲取網頁內容；傳輸完後與目的主機四次揮手來斷開TCP連線。

整個過程基本分做下面幾個部分：

• 1、域名解析成IP地址；
• 2、與目的主機進行TCP連線（三次握手）；
• 3、傳送與收取資料；
• 4、與目的主機斷開TCP連線（四次揮手）；

TCP的優點： 可靠，穩定 TCP的可靠體現在TCP在傳遞資料之前，會有三次握手來建立連線，而且在資料傳遞時，有確認、視窗、重傳、擁塞控制機制，在資料傳完後，還會斷開連線用來節約系統資源。

TCP的缺點：慢，效率低，佔用系統資源高，易被攻擊。 TCP在傳遞資料之前，要先建連線，這會消耗時間，而且在資料傳遞時，確認機制、重傳機制、擁塞控制機制等都會消耗大量的時間，而且要在每臺裝置上維護所有的傳輸連線，事實上，每個連線都會佔用系統的CPU、記憶體等硬體資源。 而且，因為TCP有確認機制、三次握手機制，這些也導致TCP容易被人利用，實現DOS、DDOS、CC等攻擊。

UDP的優點： 快，比TCP稍安全 UDP沒有TCP的握手、確認、視窗、重傳、擁塞控制等機制，UDP是一個無狀態的傳輸協議，所以它在傳遞資料時非常快。沒有TCP的這些機制，UDP較TCP被攻擊者利用的漏洞就要少一些。但UDP也是無法避免攻擊的，比如：UDP Flood攻擊……

UDP的缺點： 不可靠，不穩定 因為UDP沒有TCP那些可靠的機制，在資料傳遞時，如果網路質量不好，就會很容易丟包。

       基於上面的優缺點，那麼： 什麼時候應該使用TCP： 當對網路通訊質量有要求的時候，比如：整個資料要準確無誤的傳遞給對方，這往往用於一些要求可靠的應用，比如HTTP、HTTPS、FTP等傳輸檔案的協議，POP、SMTP等郵件傳輸的協議。 在日常生活中，常見使用TCP協議的應用如下： 瀏覽器，用的HTTP FlashFXP，用的FTP Outlook，用的POP、SMTP Putty，用的Telnet、SSH QQ檔案傳輸 ………… 什麼時候應該使用UDP： 當對網路通訊質量要求不高的時候，要求網路通訊速度能儘量的快，這時就可以使用UDP。 比如，日常生活中，常見使用UDP協議的應用如下： QQ語音 QQ視訊 TFTP ……

TCP報頭結構

16位埠號，告知主機該報文段來自哪裡（源埠號）以及傳給哪個上層協議或應用程式（目的埠）的。TCP通訊時，客戶端通常使用系統自動選擇的臨時埠號，而伺服器使用知名埠號。   

32位序號：一次TCP通訊過程中某個傳輸方向上的位元組流的每個位元組的編號。

第一個報文段中序號值被系統初始化為某個隨機值ISN，那麼該傳輸方向上後續的TCP報文段中序號值將被系統設定為ISN加上該報文段所攜帶的第一個位元組在整個位元組流的偏移。     

32位確認號：用作對另一方傳送的TCP報文段的響應。其值是收到的TCP報文段的序號值加1.假如主機A和主機B進行TCP通訊，那麼A傳送的TCP報文段不僅攜帶自己的序號，還有對B傳送來的TCP報文段的確認號。

4位頭部長度：標識該TCP頭部有多少個32bit字（4位元組），因為4位最大表示15所以TCP頭部最長是60位元組。    

6位標誌位：選項有，ACK標誌：表示確認號是否有效。將攜帶ACK標誌的TCP報文段成為“確認報文段”。SYN標誌：表示請求建立一個連線，將攜帶SYN標誌的報文段稱為“同步報文段”。   FIN標誌：表示通知對方要關閉連線，將攜帶FIN標誌的報文段稱為“結束報文段”。    

16位視窗大小：指的是接受通告視窗。它告訴接受端自己接受緩衝區還能容納多少位元組的資料。   

16位校驗和：由傳送端填充，接收端對TCP報文段執行CRC演算法檢驗報文段在傳輸中是否損壞，檢驗TCP頭部和資料部分。這是TCP可靠傳輸的一個重要保障。   16位緊急指標。。  

②頭部選項

還有最後一個選項欄位是可變長的可選資訊，最多40位元組。。。

tcp、udp的區別

1.基於面向連線與無連線。因為每個連線都會佔用系統的CPU、記憶體等硬體資源，所以對系統資源的要求TCP較多UDP少；並且tcp是一對一的，udp是一對一，一對多，多對一，多對多通訊。

2.位元組流：應用程式對資料的傳送和接受沒有邊界限制，即傳送端執行的寫操作次數和接受端的讀操作次數沒有任何數量關係，並且send只是將資料寫進發送緩衝區，recv只是從輸出緩衝區中獲取資料。【因為如果傳送端應用程式連續執行寫操作，tcp先將資料放入TCP傳送緩衝區中，等到緩衝區真正傳送資料時，資料可能被封裝了一個或多個TCP報文段發出，即TCP發出的tcp報文段個數和執行的寫操作次數沒有關係。 而接受端收到一個或多個TCP報文段，先將他們攜帶的資料按序號依次放到接受緩衝區中，通知應用程序接受。應用程式可以一次全部讀出，也可以分幾次讀出，這取決於應用程式的緩衝區大小，即TCP模組接受的報文段個數和讀操作次數沒關係。】

 資料報：sendto傳送資料和對端recvfrom接受數次數相等，因此UDP保留了應用層資料的邊界。【 傳送端應用程式每執行寫操作一次，UDP模組就將它封裝成一個數據報傳送了。接收端必須及時對每個udp資料報執行讀操作並且一次接受完，否則不讀資料會丟包，或者不讀完整資料會被截斷髮生資料丟失。】

3.tcp是可靠傳輸，通過TCP連線傳送的資料，無差錯，不丟失，不重複，且按序到達;udp是不保證可靠交付。

可靠性體現在：應用程式將資料傳送給TCP，然後TCP把資料流分割槽成適當長度的報文段（通常受該計算機連線的網路的資料鏈路層的最大傳輸單元（ MTU）的限制）之後TCP把結果包傳給IP層，由它來通過網路將包傳送給接收端實體的TCP層。TCP為了保證不發生丟包，就給每個包一個序號，同時序號也保證了傳送到接收端實體的包的按序接收。然後接收端實體對已成功收到的包發回一個相應的確認（ACK）；如果傳送端實體在合理的往返時延（RTT）內未收到確認，那麼對應的資料包就被假設為已丟失將會被進行重傳。TCP用一個校驗和函式來檢驗資料是否有錯誤；在傳送和接收時都要計算校驗和。

具體體現為：

1．應用資料被分割成TCP認為最適合傳送的資料塊。這和UDP完全不同，應用程式產生的資料長度將保持不變。由TCP傳遞給IP的資訊單位稱為報文段或段。【在TCP三次我握手的前兩次握手中（也就是兩個SYN報文段中），通過一個“協商”的方式來告知對方自己期待收到的最大報文段長度（MSS），結果使用通訊雙發較小的MSS最為最終的MSS。在SYN=1的報文段中，會在報文段的選項部分來指定MSS大小（相當於告知對方自己所能接收的最大報文段長度）。在後續通訊雙發發送應用層資料之前，如果傳送資料超過MSS，會對資料進行分段】。

2.當TCP發出一個段後，它啟動一個定時器，等待目的端確認收到這個報文段。當TCP收到發自TCP連線另一端的資料，它將傳送一個確認。TCP有延遲確認的功能，在此功能沒有開啟，則是立即確認。功能開啟，則由定時器觸發確認時間點。

3.TCP有超時重傳機制，如果沒有收到對端對於傳送報文的確認，則會重傳一份。如果傳送端在合理的往返時延（RTT）內未收到確認，那麼對應的資料包就被假設為已丟失將會被進行重傳。

4．TCP將保持它首部和資料的檢驗和。CRC對TCP整個資料報進行校驗（頭部和資料部分都會校驗）用一個校驗和函式來檢驗資料是否有錯誤；在傳送和接收時都要計算校驗和。如果收到段的檢驗和有差錯，TCP將丟棄這個報文段和不確認收到此報文段（希望發端超時並重發）。

5．既然TCP報文段作為IP資料報來傳輸，而IP資料報的到達可能會失序、重複，因此TCP報文段的到達也可能會失序。如果必要，TCP將對收到的資料進行重新排序、整理，將收到的資料以正確的順序交給應用層。【在同一次傳輸的同一個方向上每個TCP報文都有唯一的標識(序號），也保證了傳送到接收端實體的包的按序接收。然後接收端對已成確認功收到的包發回一個相應的ACK；若重複TCP的接收端必須丟棄重複的資料。】

udp和ip協議都是提供不可靠服務，它們需要上層協議來處理資料確認和超時重傳。

三次握手與四次揮手

為什麼三次握手？1.如果兩次握手，因為存在一種情況。client傳送的第一個連線請求報文段沒有丟失，而是在某個網路節點長時間滯留了，以致延誤到連線斷開後的某個時間才到伺服器。

這個失效報文段到了sever，sever以為client想建立連線，就傳送確認報文段並同意建立連線。此時若只有兩次握手，那新的連線就建立了。但由於client其實並沒建立連線，所以對確認報文段無反應，更發不了資料。可是sever以為新的連線已建立，就傻傻地一直等著發資料，導致sever很多資源被浪費掉。

所以三次握手可以防止已失效的連線請求的報文段突然到sever，使伺服器一直等待 浪費了資源。但是三次握手也有缺陷，會導致syn攻擊

Timewait是主動關閉的一端在本端已經關閉的前期下，收到對端的關閉請求（FIN報文段）並且將ACK傳送出去後所處的狀態，這種狀態表示：雙方都已經完成工作，只是為了確保遲來的資料報能被識別並丟棄；可靠的終止TCP連線。這種狀態下客戶端連線要等一段2MSL（報文段最大生存時間【2min】）的時間，才能完全關閉。

具體存在原因：①可靠的終止tcp連線。假如用於確認伺服器結束報文段的tcp報文段7丟失了，那伺服器將重發結束報文段。所以客戶端需要停留在一個狀態處理多次收到的伺服器結束報文段。（也就是向伺服器傳送確認報文段）。否則，客戶端將傳送復位報文段給伺服器，伺服器認為這是一個錯誤。

②保證讓遲來的tcp報文段有足夠時間被識別和丟棄。因為如果沒有timewait狀態，應用程式可以立即建立一個和剛關閉的相似的連結。這個連線可能接受原來連線的攜帶應用資料的tcp報文段（遲來的報文段）。因此我們此時不應該用此連結的埠號建立新連線，設為timewait狀態。然後等待2MSL（保證網路的兩個傳輸方向上遲到的報文段都消失了【被中轉路由器丟棄】時間去使遲來的報文段被識別丟棄！

CLOSE_WAIT是被動關閉的一端在接收到對端關閉請求（FIN報文段）並且將ACK傳送出去後所處的狀態，這種狀態表示：收到了對端關閉的請求，但是本端還沒有完成工作，還未關閉。

TCP的流量控制與擁塞控制

超時重傳：TCP服務必須能夠重傳超時時間內未收到確認報文段的TCP報文段。TCP為每個TCP模組都維護了一個重傳定時器，定時器在第一次傳送TCP報文段時啟動，如果超時時間內未收到接收方的確認號報文段，TCP模組將重傳TCP報文段並重置定時器。   至於下次重傳的超時時間如何選擇，以及最多重傳幾次，這是TCP的重傳策略。 與TCP超時重連的策略相似。

滑動視窗：TCP中採用滑動視窗來進行流量控制，滑動視窗的大小意味著接收方還有多大的緩衝區可以用於接收資料。傳送方可以通過滑動視窗的大小來確定應該傳送多少位元組的資料。當滑動視窗為0時，傳送方一般不能再發送資料報。

滑動視窗協議的基本原理就是在任意時刻，傳送方都維持了一個連續的允許傳送的幀的序號，稱為傳送視窗；同時，接收方也維持了一個連續的允許接收的幀的序號，稱為接收視窗。傳送視窗和接收視窗的序號的上下界不一定要一樣，甚至大小也可以不同。不同的滑動視窗協議視窗大小一般不同。傳送方視窗內的序列號代表了那些已經被髮送，但是還沒有被確認的幀，或者是那些可以被髮送的幀。

流量控制的處理過程：

TCP連線階段，雙方協商視窗尺寸，同時接收方預留資料快取區；

傳送方根據協商的結果，傳送符合視窗尺寸的資料位元組流，並等待對方的確認；

傳送方根據確認資訊，改變視窗的尺寸，增加或者減少傳送未得到確認的位元組流中的位元組數。調整過程包括：如果出現傳送擁塞，傳送視窗縮小為原來的一半，同時將超時重傳的時間間隔擴大一倍。

TCP的擁塞控制，流量控制

擁塞控制：TCP模組為了防止過多的資料注入網路，使網路中的路由器或鏈路不致於過載。以此提高網路利用率，降低丟包率，並抱證網路資源對每條資料流的公平性而採取的控制手段。擁塞控制包含四部分內容：慢啟動、擁塞避免、快速重傳、快速恢復。

        慢啟動：  網路傳輸剛開始時，並不知道網路的實際情況，所以採取一種試探的方式控制資料的傳送速率。慢啟動階段，資料的傳送速率以指數方式增長，即就是擁塞視窗的增長，每次都是收到確認報文段數量的2倍。可以看出慢啟動並不慢，擁塞視窗增長的速度很快。所以，為其設定了一個慢啟動門限，當達到門限時，就進入到擁塞避免階段。

        擁塞避免： 當擁塞視窗的大小採用慢啟動方式增長到慢啟動門限時，就進入擁塞避免階段，擁塞避免階段不再以指數形式增長擁塞視窗，而是每經過一個往返時間RTT就將傳送方的擁塞視窗+1， 使其增長速度減緩。按照線性方式增長。如果發生網路擁塞，比如丟包時，就將慢啟動門限設為原來的一半，然後將擁塞視窗設定為1，開始執行慢啟動演算法。（較低的起點，指數級增長）。

        快速重傳： 假設傳送方傳送的報文段分別為： M1,M2,M3,M4,M5,M6 , 當接收方收到M1和M2後，M3報文段丟失，接著收到的M4，M5，M6都不做處理，而是沒接收到一個報文段就對M2重複確認，傳送方接收到重複的三次確認報文段，就對其後的報文段進行重新發送，而不需要等待超時時間到達。當快速重傳後，立即進入到快速恢復階段。

        快速恢復：將慢啟動門限設定為原來的一半，然後將擁塞視窗設定為現在的慢啟動門限值，不再執行慢啟動演算法，而是直接進入擁塞避免階段。使傳送視窗成線性方式增大。

流量控制（滑動視窗協議）TCP連線的每一方都有固定大小的緩衝空間。TCP的接收端只允許另一端傳送接收端緩衝區所能接納的資料。這將防止較快主機致使較慢主機的緩衝區溢位。【滑動視窗技術存在於資料鏈路層和傳輸層。兩者有不同的協議，但基本原理相同。區別是一個是傳送幀，一個是傳送位元組資料。接收方的接受視窗告訴傳送方本端tcp接受緩衝區還能容納多少位元組，傳送方的傳送視窗就可以控制傳送資料的速度。】

UDP沒有流量控制和擁塞控制，所以在網路擁塞時不會是源主機發送速率降低（對實時通訊很有用，比如QQ電話，視訊會議等）