tcp和udp都屬於傳輸層協議
第一次握手：建立連線時，客戶端傳送syn包（syn=j）到伺服器，並進入syn_sent狀態，等待伺服器確認；syn：同步序列編號（synchronize sequence numbers）。
第二次握手：伺服器收到syn包，必須確認客戶的syn（ack=j+1），同時自己也傳送乙個syn包（syn=k），即syn+ack包，此時伺服器進入syn_recv狀態；
第三次握手：客戶端收到伺服器的syn+ack包，向伺服器傳送確認包ack(ack=k+1），此包傳送完畢，客戶端和伺服器進入established（tcp連線成功）狀態，完成三次握手。
第一次揮手：客戶端a傳送乙個fin，用來關閉客戶a到伺服器b的資料傳送
第二次揮手：伺服器b收到這個fin，它發回乙個ack，確認序號為收到的序號加1。和syn一樣，乙個fin將占用乙個序號。
第三次揮手：伺服器b關閉與客戶端a的連線，傳送乙個fin給客戶端a
第四次揮手：客戶端a發回ack報文確認，並將確認序號設定為收到序號加1
tcp的三次握手最主要是防止已過期的連線再次傳到被連線的主機。
如果採用兩次的話，會出現下面這種情況。
比如是a機要連到b機，結果傳送的連線資訊由於某種原因沒有到達b機；
於是，a機又發了一次，結果這次b收到了，於是就發資訊回來，兩機就連線。
傳完東西後，斷開。
結果這時候，原先沒有到達的連線資訊突然又傳到了b機，於是b機發資訊給a，然後b機就以為和a連上了，這個時候b機就在等待a傳東西過去。
因為連線時，呼叫socket的connect函式傳送syn包，而伺服器端只是accept一下，就一次傳送了syn和ack標誌位，而到了斷開連線時客戶端傳送fin包表示客戶端已經沒有要發的東西了，但是此時服務端可能還要要傳送的東西，得等服務端傳送完該發的東西才能向客戶端傳送fin包，所以兩次close分別觸發了兩次fin包，導致沒有和ack合併為乙個包，所以連線要3次，斷開要4次。
msl(maximum segment lifetime)的英文縮寫，最長報文段壽命，它是任何報文在網路上存在的最長時間，超過這個時間報文段將被丟棄。兩個理由：
假設客戶端不等待2msl，而是在傳送完ack之後直接釋放關閉，一旦這個ack丟失，伺服器就無法正常的進入關閉連線狀態。之所以等待2msl就是用來重發可能丟失的ack報文。
客戶端在傳送完最後乙個ack報文段後，再經過2msl，就可以使本連線持續時間內所產生的所有報文段都從網路中消失，使下乙個新的連線中不會出現這種就得連線請求報文段。
如何理解tcp是面向位元組流，udp是面向資料報的？
tcp面向位元組流：雖然應用程式和tcp的互動是一次乙個資料塊（大小不等），但是tcp把應用程式交下來的資料僅僅看成是一連串的無結構的位元組流，tcp並不知道所傳送的位元組流的含義。如果應用程序傳送到tcp快取的資料塊太長，tcp就可以把它劃分短一些再傳送，如果資料塊太短，也可以累積幾次一起傳送。
udp面向報文：udp對應用層交下來的報文，既不合併也不拆分，而是保留這些報文的邊界，也就是說應用層交給udp多長報文，udp照常傳送，一次傳送乙個報文。在互通之前，面向連線的協議在彼此交換資料之前會先建立乙個tcp連線。在乙個tcp連線中，僅有兩方進行彼此通訊。
tcp將應用層交接下來的資料封裝成一串無結構的位元組流，tcp並不知道它的實際含義。如果資料太長則分塊，太短則合併。
tcp有超時重傳機制，通過設定rto(定時器)的時間從而保證網路資源最小的被浪費。rto一般根據rtt(傳輸往返時間)來自動調整。
當一端收到另一端的資料時，將傳送乙個ack包，這個ack包不是立即傳送，會推遲幾毫秒。因為要對包做完整性校驗。
tcp將保持它的首部和資料的校驗和。這是乙個端到端的校驗和，目的是檢測資料在傳輸過程中的變化。如果收到的檢驗和有差錯，tcp將會丟棄該報文段。
tcp會保證資料有序傳輸。每次傳送資料時，tcp會給每個資料報分配乙個序列號並且在乙個特定的時間內等待接主機確認，主機一旦確認則會將這些資料重組成資料流並傳輸給其它層處理。
流量控制和擁塞機制，詳情**
是指多個程序在執行過程中因爭奪資源而造成的一種僵局，當程序處於這種僵持狀態時，若無外力作用，它們都將無法再向前推進。
產生死鎖的原因：
可歸結為如下兩點：
a. 競爭資源
系統中的資源可以分為兩類：
可剝奪資源，是指某程序在獲得這類資源後，該資源可以再被其他程序或系統剝奪，cpu和主存均屬於可剝奪性資源；
另一類資源是不可剝奪資源，當系統把這類資源分配給某程序後，再不能強行收回，只能在程序用完後自行釋放，如磁帶機、印表機等。
產生死鎖中的競爭資源之一指的是競爭不可剝奪資源（例如：系統中只有一台印表機，可供程序p1使用，假定p1已占用了印表機，若p2繼續要求印表機列印將阻塞）
產生死鎖中的競爭資源另外一種資源指的是競爭臨時資源（臨時資源包括硬體中斷、訊號、訊息、緩衝區內的訊息等），通常訊息通訊順序進行不當，則會產生死鎖
b. 程序間推進順序非法
若p1保持了資源r1,p2保持了資源r2，系統處於不安全狀態，因為這兩個程序再向前推進，便可能發生死鎖
例如，當p1執行到p1：request（r2）時，將因r2已被p2占用而阻塞；當p2執行到p2：request（r1）時，也將因r1已被p1占用而阻塞，於是發生程序死鎖
死鎖產生的4個必要條件
互斥條件
請求和保持條件
不剝奪條件
環路等待條件。
a：死鎖預防
有序資源分配法
這種演算法資源按某種規則系統中的所有資源統一編號（例如印表機為1、磁帶機為2、磁碟為3、等等），申請時必須以上公升的次序。系統要求申請程序：
1、對它所必須使用的而且屬於同一類的所有資源，必須一次申請完；
2、在申請不同類資源時，必須按各類裝置的編號依次申請。例如：程序pa，使用資源的順序是r1，r2； 程序pb，使用資源的順序是r2，r1；若採用動態分配有可能形成環路條件，造成死鎖。
採用有序資源分配法：r1的編號為1，r2的編號為2；
pa：申請次序應是：r1，r2
pb：申請次序應是：r1，r2
這樣就破壞了環路條件，避免了死鎖的發生
銀行家演算法
避免死鎖演算法中最有代表性的演算法是dijkstra e.w 於2023年提出的銀行家演算法：
銀行家演算法通過先 試探 再分配的原則給該程序資源，然後通過安全性演算法判斷分配後的系統是否處於安全狀態，若不安全則試探分配作廢，讓該程序繼續等待。
b:解決方法
先檢測：這種方法並不須事先採取任何限制性措施，也不必檢查系統是否已經進入不安全區，此方法允許系統在執行過程中發生死鎖。但可通過系統所設定的檢測機構，及時地檢測出死鎖的發生，並精確地確定與死鎖有關的程序和資源。檢測方法包括定時檢測、效率低時檢測、程序等待時檢測等。
然後解除死鎖：採取適當措施，從系統中將已發生的死鎖清除掉。
這是與檢測死鎖相配套的一種措施。當檢測到系統中已發生死鎖時，須將程序從死鎖狀態中解脫出來。常用的實施方法是撤銷或掛起一些程序，以便**一些資源，再將這些資源分配給已處於阻塞狀態的程序，使之轉為就緒狀態，以繼續執行。死鎖的檢測和解除措施，有可能使系統獲得較好的資源利用率和吞吐量，但在實現上難度也最大。
如果我們在死鎖檢查時發現了死鎖情況，那麼就要努力消除死鎖，使系統從死鎖狀態中恢復過來。消除死鎖的幾種方式：
最簡單、最常用的方法就是進行系統的重新啟動，不過這種方法代價很大，它意味著在這之前所有的程序已經完成的計算工作都將付之東流，包括參與死鎖的那些程序，以及未參與死鎖的程序；
撤消程序，剝奪資源。終止參與死鎖的程序，收回它們占有的資源，從而解除死鎖。這時又分兩種情況：一次性撤消參與死鎖的全部程序，剝奪全部資源；或者逐步撤消參與死鎖的程序，逐步收回死鎖程序占有的資源。一般來說，選擇逐步撤消的程序時要按照一定的原則進行，目的是撤消那些代價最小的程序，比如按程序的優先順序確定程序的代價；考慮程序執行時的代價和與此程序相關的外部作業的代價等因素；
程序回退策略，即讓參與死鎖的程序回退到沒有發生死鎖前某一點處，並由此點處繼續執行，以求再次執行時不再發生死鎖。雖然這是個較理想的辦法，但是操作起來系統開銷極大，要有堆疊這樣的機構記錄程序的每一步變化，以便今後的回退，有時這是無法做到的。
tcp三次握手 以及四次揮手
首先client端傳送連線請求報文，server段接受連線後回覆ack報文，並為這次連線分配資源。client端接收到ack報文後也向server段發生ack報文，並分配資源，這樣tcp連線就建立了。那如何斷開連線呢？簡單的過程如下 注意 中斷連線端可以是client端，也可以是server端。假設...
TCP三次握手 四次揮手
tcp 三次握手 tcp 連線是通過三次握手進行初始化的。三次握手的目的是同步連線雙方的序列號和確認號並交換 tcp 視窗大小資訊。以下步驟概述了通常情況下客戶端計算機聯絡伺服器計算機的過程 1.客戶端向伺服器傳送乙個syn置位的tcp報文，其中包含連線的初始序列號x和乙個視窗大小 表示客戶端上用來...
TCP三次握手 四次揮手
服務端的tcp程序先建立傳輸控制塊tcb，準備接受客戶端程序的連線請求，然後服務端程序處於listen狀態，等待客戶端的連線請求，如有，則作出響應。1 客戶端的tcp程序也首先建立傳輸控制模組tcb，然後向服務端發出連線請求報文段，該報文段首部中的syn 1，ack 0，同時選擇乙個初始序號seq ...