TCP和UDP的區別？TCP三次握手
- 1）TCP和UDP區別
【1】 連接
TCP是面向連接的傳輸層協議，即傳輸數據之前必須先建立好連接。
UDP無連接。
【2】 服務對象
TCP是點對點的兩點間服務，即一條TCP連接只能有兩個端點；
UDP具有多播的特點，支持一對一，一對多，多對一，多對多的交互通信。
【3】 可靠性
TCP是可靠交付：無差錯，不丟失，不重複，按序到達。
UDP是盡最大努力交付，不保證可靠交付。
【4】擁塞控制，流量控制
TCP有擁塞控制和流量控制保證數據傳輸的安全性。
UDP沒有擁塞控制，網絡擁塞不會影響源主機的發送效率。
【5】 報文長度
TCP是動態報文長度，即TCP報文長度是由接收方的窗口大小和當前網絡擁塞情況決定的。
UDP面向報文，不合並，不拆分，保留上面傳下來報文的邊界。
【6】 首部開銷
TCP首部開銷大，首部20個字節。
UDP首部開銷小，8字節。（源端口，目的端口，數據長度，校驗和）
- 2）TCP和UDP適用場景
從特點上我們已經知道，TCP 是可靠的但傳輸速度慢，UDP 是不可靠的但傳輸速度快。因此在選用具體協議通信時，應該根據通信數據的要求而決定。
若通信數據完整性需讓位與通信實時性，則應該選用TCP 協議（如文件傳輸、重要狀態的更新等）；反之，則使用 UDP 協議（如視頻傳輸、實時通信等）。
- 三次握手過程理解
第一次握手：
客戶端A：發送SYN連接報文，序列號爲x，進入SYNC-SENT狀態。
第二次握手：
服務端B：發送SYN連接確認報文（SYN=1，ACK = 1），序列號爲y（seq = y），確認報文x（ack = x + 1），進入SYNC-RCVD狀態。
第三次握手：
客戶端A：發送ACK確認報文（ACK = 1），序列號爲x+1（seq = x + 1），確認報文y+1（ack = y + 1），進入ESTABLISHED狀態。
服務器B：收到後進入ESTABLISHED狀態。
三次握手的原因：
三次握手可以防止已經失效的連接請求報文突然又傳輸到服務器端導致的服務器資源浪費。
客戶端發出去的第一個連接請求由於某些原因在網絡節點中滯留了導致延遲，直到連接釋放的某個時間點纔到達服務端，這是一個早已失效的報文，但是此時服務端仍然認爲這是客戶端的建立連接請求第一次握手，於是服務端迴應了客戶端，第二次握手。此時，客戶端仍認爲連接未建立，服務器會對已建立的連接保存必要的資源，如果大量的這種情況，服務器會崩潰。
（本質原因）tcp是全雙工通信，兩次握手只能確定單向數據鏈路是可以通信的，並不能保證反向的通信正常
- 四次揮手過程理解
第一次揮手：
服務端A：發送FIN報文（FIN = 1），序列號爲u（seq = u），進入FIN-WAIT 1狀態。
第二次揮手：
客戶端B：發送ACK確認報文（ACK = 1），序列號爲v（seq = v），確認報文u（ack = u + 1），進入CLOSE-WAIT狀態，繼續傳送數據。
服務端A：收到上述報文進入FIN-WAIT2狀態，繼續接受B傳輸的數據。
第三次揮手：
客戶端B：數據傳輸完畢後，發送FIN報文（FIN = 1，ACK = 1），序列號爲w（seq = w），確認報文u（ack = u + 1），進入LAST-ACK狀態。
第四次揮手：
服務端A：發送ACK確認報文（ACK = 1），序列號爲u+1（seq = u + 1），確認報文w（ack = w + 1），進入TIME-WAIT狀態，等待2MSL（最長報文段壽命），進入CLOSED狀態。
客戶端B：收到後上述報文後進入CLOSED狀態。
1）客戶端進程發出連接釋放報文，並且停止發送數據。釋放數據報文首部，FIN=1，其序列號爲seq=u（等於前面已經傳送過來的數據的最後一個字節的序號加1），此時，客戶端進入FIN-WAIT-1（終止等待1）狀態。 TCP規定，FIN報文段即使不攜帶數據，也要消耗一個序號。
2）服務器收到連接釋放報文，發出確認報文，ACK=1，ack=u+1，並且帶上自己的序列號seq=v，此時，服務端就進入了CLOSE-WAIT（關閉等待）狀態。TCP服務器通知高層的應用進程，客戶端向服務器的方向就釋放了，這時候處於半關閉狀態，即客戶端已經沒有數據要發送了，但是服務器若發送數據，客戶端依然要接受。這個狀態還要持續一段時間，也就是整個CLOSE-WAIT狀態持續的時間。
3）客戶端收到服務器的確認請求後，此時，客戶端就進入FIN-WAIT-2（終止等待2）狀態，等待服務器發送連接釋放報文（在這之前還需要接受服務器發送的最後的數據）。
4）服務器將最後的數據發送完畢後，就向客戶端發送連接釋放報文，FIN=1，ack=u+1，由於在半關閉狀態，服務器很可能又發送了一些數據，假定此時的序列號爲seq=w，此時，服務器就進入了LAST-ACK（最後確認）狀態，等待客戶端的確認。
5）客戶端收到服務器的連接釋放報文後，必須發出確認，ACK=1，ack=w+1，而自己的序列號是seq=u+1，此時，客戶端就進入了TIME-WAIT（時間等待）狀態。注意此時TCP連接還沒有釋放，必須經過2∗∗MSL（最長報文段壽命）的時間後，當客戶端撤銷相應的TCB後，才進入CLOSED狀態。
6）服務器只要收到了客戶端發出的確認，立即進入CLOSED狀態。同樣，撤銷TCB後，就結束了這次的TCP連接。可以看到，服務器結束TCP連接的時間要比客戶端早一些。
四次揮手的原因：
1、當客戶端確認發送完數據且知道服務器已經接收完了，想要關閉發送數據口（當然確認信號還是可以發），就會發FIN給服務器。
2、服務器收到客戶端發送的FIN，表示收到了，就會發送ACK回覆。
3、但這時候服務器可能還在發送數據，沒有想要關閉數據口的意思，所以服務器的FIN與ACK不是同時發送的，而是等到服務器數據發送完了，纔會發送FIN給客戶端。
4、客戶端收到服務器發來的FIN，知道服務器的數據也發送完了，回覆ACK， 客戶端等待2MSL以後，沒有收到服務器傳來的任何消息，知道服務器已經收到自己的ACK了，客戶端就關閉鏈接，服務器也關閉鏈接了。
另一種：
由於連接的關閉控制權在應用層，所以被動關閉的一方在接收到FIN包時，TCP協議棧會直接發送一個ACK確認包，優先關閉一端的通信。然後通知應用層，由應用層決定什麼時候發送FIN包。應用層可以使用系統調用函數read==0來判斷對端是否關閉連接。
2MSL意義：
1、爲了保證 A 發送的最後一個 ACK 報文段能夠到達 B。
2、防止 “已失效的連接請求報文段”出現在本連接中。2MSL後，這次連接的所有報文都會消失，不會影響下一次連接。
（詳細版）A 在發送完最後一個 ACK 報文段後，再經過時間 2MSL，就可以使本連接持續的時間內所產生的所有報文段，都從網絡中消失。這樣就可以使下一個新的連接中不會出現這種舊的連接請求報文段。
TCP保證可靠性：
（1）序列號、確認應答、超時重傳
數據到達接收方，接收方需要發出一個確認應答，表示已經收到該數據段，並且確認序號會說明了它下一次需要接收的數據序列號。如果發送發遲遲未收到確認應答，那麼可能是發送的數據丟失，也可能是確認應答丟失，這時發送方在等待一定時間後會進行重傳。這個時間一般是2*RTT(報文段往返時間）+一個偏差值。
（2）窗口控制與高速重發控制/快速重傳（重複確認應答）
TCP會利用窗口控制來提高傳輸速度，意思是在一個窗口大小內，不用一定要等到應答才能發送下一段數據，窗口大小就是無需等待確認而可以繼續發送數據的最大值。如果不使用窗口控制，每一個沒收到確認應答的數據都要重發。
使用窗口控制，如果數據段1001-2000丟失，後面數據每次傳輸，確認應答都會不停地發送序號爲1001的應答，表示我要接收1001開始的數據，發送端如果收到3次相同應答，就會立刻進行重發；但還有種情況有可能是數據都收到了，但是有的應答丟失了，這種情況不會進行重發，因爲發送端知道，如果是數據段丟失，接收端不會放過它的，會瘋狂向它提醒......
（3）擁塞控制
如果把窗口定的很大，發送端連續發送大量的數據，可能會造成網絡的擁堵（大家都在用網，你在這狂發，吞吐量就那麼大，當然會堵），甚至造成網絡的癱瘓。所以TCP在爲了防止這種情況而進行了擁塞控制。
慢啓動：定義擁塞窗口，一開始將該窗口大小設爲1，之後每次收到確認應答（經過一個rtt），將擁塞窗口大小*2。
擁塞避免：設置慢啓動閾值，一般開始都設爲65536。擁塞避免是指當擁塞窗口大小達到這個閾值，擁塞窗口的值不再指數上升，而是加法增加（每次確認應答/每個rtt，擁塞窗口大小+1），以此來避免擁塞。
將報文段的超時重傳看做擁塞，則一旦發生超時重傳，我們需要先將閾值設爲當前窗口大小的一半，並且將窗口大小設爲初值1，然後重新進入慢啓動過程。
快速重傳：在遇到3次重複確認應答（高速重發控制）時，代表收到了3個報文段，但是這之前的1個段丟失了，便對它進行立即重傳。
然後，先將閾值設爲當前窗口大小的一半，然後將擁塞窗口大小設爲慢啓動閾值+3的大小。
這樣可以達到：在TCP通信時，網絡吞吐量呈現逐漸的上升，並且隨着擁堵來降低吞吐量，再進入慢慢上升的過程，網絡不會輕易的發生癱瘓。
UDP如何實現可靠傳輸？
最簡單的方式是在應用層模仿傳輸層TCP的可靠性傳輸。下面不考慮擁塞處理，可靠UDP的簡單設計。
- 1、添加seq/ack機制，確保數據發送到對端
- 2、添加發送和接收緩衝區，主要是用戶超時重傳。
- 3、添加超時重傳機制。
詳細說明：送端發送數據時，生成一個隨機seq=x，然後每一片按照數據大小分配seq。數據到達接收端後接收端放入緩存，併發送一個ack=x的包，表示對方已經收到了數據。發送端收到了ack包後，刪除緩衝區對應的數據。時間到後，定時任務檢查是否需要重傳數據。
四層TCP/IP模型
TCP/IP 4層模型包括：
網絡接口層：MAC VLAN
網絡層:IP ARP ICMP
傳輸層:TCP UDP
應用層:HTTP DNS SMTP
OSI七層模型及其包含的協議如下:
物理層: 通過媒介傳輸比特,確定機械及電氣規範,傳輸單位爲bit，主要包括的協議爲：IEE802.3 CLOCK RJ45
數據鏈路層: 將比特組裝成幀和點到點的傳遞,傳輸單位爲幀,主要包括的協議爲MAC VLAN PPP
網絡層：負責數據包從源到宿的傳遞和網際互連，傳輸單位爲包,主要包括的協議爲IP ARP ICMP
傳輸層：提供端到端的可靠報文傳遞和錯誤恢復，傳輸單位爲報文,主要包括的協議爲TCP UDP
會話層：建立、管理和終止會話，傳輸單位爲SPDU，主要包括的協議爲RPC NFS
表示層: 對數據進行翻譯、加密和壓縮,傳輸單位爲PPDU，主要包括的協議爲JPEG ASII
應用層: 允許訪問OSI環境的手段,傳輸單位爲APDU，主要包括的協議爲FTP HTTP DNS
請你說一說TCP擁塞控制？以及達到什麼情況的時候開始減慢增長的速度？
擁塞控制是防止過多的數據注入網絡，使得網絡中的路由器或者鏈路過載。流量控制是點對點的通信量控制，而擁塞控制是全局的網絡流量整體性的控制。發送雙方都有一個擁塞窗口——cwnd。
1、慢開始
最開始發送方的擁塞窗口爲1，由小到大逐漸增大發送窗口和擁塞窗口。每經過一個傳輸輪次，擁塞窗口cwnd加倍。當cwnd超過慢開始門限，則使用擁塞避免算法，避免cwnd增長過大。
2、擁塞避免
每經過一個往返時間RTT，cwnd就增長1。
在慢開始和擁塞避免的過程中，一旦發現網絡擁塞，就把慢開始門限設爲當前值的一半，並且重新設置cwnd爲1，重新慢啓動。（乘法減小，加法增大）
3、快重傳
接收方每次收到一個失序的報文段後就立即發出重複確認，發送方只要連續收到三個重複確認就立即重傳（儘早重傳未被確認的報文段）。
4、快恢復
當發送方連續收到了三個重複確認，就乘法減半（慢開始門限減半），將當前的cwnd設置爲慢開始門限，並且採用擁塞避免算法（連續收到了三個重複請求，說明當前網絡可能沒有擁塞）。
採用快恢復算法時，慢開始只在建立連接和網絡超時才使用。
達到什麼情況的時候開始減慢增長的速度？
採用慢開始和擁塞避免算法的時候
1. 一旦cwnd>慢開始門限，就採用擁塞避免算法，減慢增長速度
2. 一旦出現丟包的情況，就重新進行慢開始，減慢增長速度
採用快恢復和快重傳算法的時候
1. 一旦cwnd>慢開始門限，就採用擁塞避免算法，減慢增長速度
2. 一旦發送方連續收到了三個重複確認，就採用擁塞避免算法，減慢增長速度
請你說一說TCP/IP數據鏈路層的交互過程
網絡層等到數據鏈層用mac地址作爲通信目標，數據包到達網絡等準備往數據鏈層發送的時候，首先會去自己的arp緩存表(存着ip-mac對應關係)去查找改目標ip的mac地址，如果查到了，就講目標ip的mac地址封裝到鏈路層數據包的包頭。如果緩存中沒有找到，會發起一個廣播：who is ip XXX tell ip XXX,所有收到的廣播的機器看這個ip是不是自己的，如果是自己的，則以單撥的形式將自己的mac地址回覆給請求的機器
輸入一個網址發生了什麼
總的來說,分爲網絡通信和頁面渲染.
應用層(http)–傳輸層(tcp)–網絡層(ip)–數據鏈路層(網絡)
1\dns解析域名(可能會查找緩存,頁面相應時間不一致)
2\tcp建立連接(三次握手)
3\應用層客戶端發送http請求(包括請求頭和請求主體)
4\網絡層IP協議查地址.
5\數據到達數據鏈路層,這時候客戶端請求結束.
6\服務器接收數據.
7/服務器相應請求,發出html響應,返回狀態碼200 OK，表示服務器可以響應請求，返回報文，由於在報頭中Content-type爲“text/html”，瀏覽器以HTML形式呈現，而不是下載文件。
8/服務器返回相關文件.
9/頁面渲染.
https://blog.csdn.net/qq_33591903/article/details/84246177