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 ……
- 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電話，視頻會議等）