向上 重新啟動 應該 開始 不發送 開發 釋放 還要 knowledge

目錄：

31.Tcp握手的一些問題？

21.Tcp三次握手及SYN攻擊；

四次握手？ 為什麽建立連接是三次握手，而關閉連接卻是四次揮手？

13.TCP釋放連接四次握手

12.TCP建立連接三次握手

11.TCP報文段首部格式?

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

31.連接建立，為什麽要進行三次握手呢（兩次確認）？

為什麽要采用三次握手，兩次不行嗎？

Tcp4次釋放連接的過程?

四次揮手圖示： 當客戶A 沒有東西要發送時就要釋放 A 這邊的連接，A會發送一個報文（沒有數據），其中 FIN 設置為1, 服務器B收到後會給應用程序一個信，這時A那邊的連接已經關閉，即A不再發送信息（但仍可接收信息）。 A收到B的確認後進入等待狀態，等待B請求釋放連接， B數據發送完成後就向A請求連接釋放，也是用FIN=1 表示， 並且用 ack = u+1(如圖）， A收到後回復一個確認信息，並進入 TIME_WAIT 狀態， 等待 2MSL 時間。 當客戶A 沒有東西要發送時就要釋放 A 這邊的連接，A會發送一個報文（沒有數據），其中 FIN 設置為1, 服務器B收到後會給應用程序一個信，這時A那邊的連接已經關閉，即A不再發送信息（但仍可接收信息)。A收到B的確認後進入等待狀態，等待B請求釋放連接， B數據發送完成後就向A請求連接釋放，也是用FIN=1 表示， 並且用 ack = u+1(如圖)， A收到後回復一個確認信息，並進入 TIME_WAIT 狀態， 等待 2MSL 時間。 為什麽要等待 2MSL 時間？ 為了這種情況： B向A發送 FIN = 1 的釋放連接請求，但這個報文丟失了，A沒有接到不會發送確認信息， B 超時會重傳，這時A在 WAIT_TIME 還能夠接收到這個請求，這時再回復一個確認就行了。（A收到 FIN = 1 的請求後 WAIT_TIME會重新記時）; 另外服務器B存在一個保活狀態，即如果A突然故障死機了，那B那邊的連接資源什麽時候能釋放呢？ 就是保活時間到了後，B會發送探測信息， 以決定是否釋放連接。

然後連接建立，為什麽要進行三次握手呢（兩次確認）? 建立三次握手主要是因為A發送了再一次的確認，那麽A為什麽會再確認一次呢，主要是為了防止已失效的連接請求報文段又突然傳送給B，從而產生了錯誤。 所謂“已失效的連接請求報文”是這樣產生的，正常情況下，A發出連接請求，但是因為連接報文請求丟失而未收到確認，於是A再重傳一次連接請求，後來收到了請求，並收到了確認，建立了連接，數據傳輸完畢後，就釋放鏈接，A共發送了兩次連接請求報文段，其中第一個丟失，第二個到達了B，沒有“已失效的連接請求報文段”，但是還有異常情況下，A發送的請求報文連接段並沒有丟失，而是在某個網絡節點滯留較長時間，以致延誤到請求釋放後的某個時間到達B，本來是一個早已失效的報文段，但是B收到了此失效連接請求報文段後，就誤以為A又重新發送的連接請求報文段，並發送確認報文段給A，同意建立連接，如果沒有三次握手，那麽B發送確認後，連接就建立了，而此時A沒有發送建立連接的請求報文段，於是不理會B的確認，也不會給B發送數據，而B卻一直等待A發送數據，因此B的許多資源就浪費了， 采用三次握手的方式就可以防止這種事情發生，例如剛剛，A不理會B，就不會給B發送確認，B收不到A的確認，就知道A不要求建立連接，就不會白白浪費資源， 為什麽連接的時候是三次握手，關閉的時候卻是四次握手？ 答：因為當Server端收到Client端的SYN連接請求報文後，可以直接發送SYN+ACK報文。其中ACK報文是用來應答的，SYN報文是用來同步的。但是關閉連接時，當Server端收到FIN報文時，很可能並不會立即關閉SOCKET，所以只能先回復一個ACK報文，告訴Client端，"你發的FIN報文我收到了"。只有等到我Server端所有的報文都發送完了，我才能發送FIN報文，因此不能一起發送。故需要四步握手。 為什麽要等待呢？ 為了這種情況： B向A發送 FIN = 1 的釋放連接請求，但這個報文丟失了， A沒有接到不會發送確認信息， B 超時會重傳，這時A在 WAIT_TIME 還能夠接收到這個請求，這時再回復一個確認就行了。（A收到 FIN = 1 的請求後 WAIT_TIME會重新記時） 另外服務器B存在一個保活狀態，即如果A突然故障死機了，那B那邊的連接資源什麽時候能釋放呢？ 就是保活時間到了後，B會發送探測信息， 以決定是否釋放連接 1.為什麽建立連接協議是三次握手，而關閉連接卻是四次握手呢？ 這是因為服務端的LISTEN狀態下的SOCKET當收到SYN報文的建連請求後，它可以把ACK和SYN（ACK起應答作用，而SYN起同步作用）放在一個報文裏來發送。但關閉連接時，當收到對方的FIN報文通知時，它僅僅表示對方沒有數據發送給你了；但未必你所有的數據都全部發送給對方了，所以你可以未必會馬上會關閉SOCKET,也即你可能還需要發送一些數據給對方之後，再發送FIN報文給對方來表示你同意現在可以關閉連接了，所以它這裏的ACK報文和FIN報文多數情況下都是分開發送的。 1.為什麽連接的時候是三次握手，關閉的時候卻是四次握手？ 答：因為當Server端收到Client端的SYN連接請求報文後，可以直接發送SYN+ACK報文。其中ACK報文是用來應答的，SYN報文是用來同步的。但是關閉連接時，當Server端收到FIN報文時，很可能並不會立即關閉SOCKET，所以只能先回復一個ACK報文，告訴Client端，"你發的FIN報文我收到了"。只有等到我Server端所有的報文都發送完了，我才能發送FIN報文，因此不能一起發送。故需要四步握手。 2.為什麽TIME_WAIT狀態還需要等2MSL後才能返回到CLOSED狀態？ 這是因為雖然雙方都同意關閉連接了，而且握手的4個報文也都協調和發送完畢，按理可以直接回到CLOSED狀態（就好比從SYN_SEND狀態到ESTABLISH狀態那樣）；但是因為我們必須要假想網絡是不可靠的，你無法保證你最後發送的ACK報文會一定被對方收到，因此對方處於LAST_ACK狀態下的SOCKET可能會因為超時未收到ACK報文，而重發FIN報文，所以這個TIME_WAIT狀態的作用就是用來重發可能丟失的ACK報文。 2.為什麽TIME_WAIT狀態需要經過2MSL(最大報文段生存時間)才能返回到CLOSE狀態？ 答：雖然按道理，四個報文都發送完畢，我們可以直接進入CLOSE狀態了，但是我們必須假象網絡是不可靠的，有可以最後一個ACK丟失。所以TIME_WAIT狀態就是用來重發可能丟失的ACK報文。

20.TCP（Transmission Control Protocol，傳輸控制協議） 是面向連接的協議，也就是說在收發數據之前，必須先和對方建立連接，一個TCP連接必須要經過三次“對話”才能建立起來，其中的過程非常復雜， 只簡單的 描述下這三次對話的簡單過程：主機A向主機B發出連接請求數據包：“我想給你發數據，可以嗎？”，這是第一次對話；主機B向主機A發送同意連接和要求同步 （同步就是兩臺主機一個在發送，一個在接收，協調工作）的數據包：“可以，你什麽時候發？”，這是第二次對話；主機A再發出一個數據包確認主機B的要求同 步：“我現在就發，你接著吧！”，這是第三次對話。三次“對話”的目的是使數據包的發送和接收同步，經過三次“對話”之後，主機A才向主機B正式發送數據。 需要了解的信息： ACK ：TCP協議規定，只有ACK=1時有效，也規定連接建立後所有發送的報文的ACK必須為1 SYN(SYNchronization) ：在連接建立時用來同步序號。當SYN=1而ACK=0時，表明這是一個連接請求報文。 對方若同意建立連接，則應在響應報文中使SYN=1和ACK=1. 因此, SYN置1就表示這是一個連接請求或連接接受報文。

21、三次握手 所謂三次握手（Three-Way Handshake）即建立TCP連接，就是指建立一個TCP連接時，需要客戶端和服務端總共發送3個包以確認連接的建立。在socket編程中，這一過程由客戶端執行connect來觸發，整個流程TCP三次握手如下所示：

三次握手的過程： 首先由Client發出請求連接即 SYN=1 ACK=0 (請看頭字段的介紹), TCP規定SYN=1時不能攜帶數據，但要消耗一個序號,因此聲明自己的序號是 seq=x； 然後 Server 進行回復確認，即 SYN=1 ACK=1 seq=y, ack=x+1； 再然後 Client 再進行一次確認，但不用SYN 了，這時即為 ACK=1, seq=x+1, ack=y+1。 （1）第一次握手：Client將標誌位SYN置為1，隨機產生一個值seq=J，並將該數據包發送給Server，Client進入SYN_SENT狀態，等待Server確認。 （2）第二次握手：Server收到數據包後由標誌位SYN=1知道Client請求建立連接，Server將標誌位SYN和ACK都置為1，ack=J+1，隨機產生一個值seq=K，並將該數據包發送給Client以確認連接請求，Server進入SYN_RCVD狀態。 （3）第三次握手：Client收到確認後，檢查ack是否為J+1，ACK是否為1，如果正確則將標誌位ACK置為1，ack=K+1，並將該數據包發送給Server，Server檢查ack是否為K+1，ACK是否為1，如果正確則連接建立成功，Client和Server進入ESTABLISHED狀態，完成三次握手，隨後Client與Server之間可以開始傳輸數據了。 SYN攻擊： 在三次握手過程中，Server發送SYN-ACK之後，收到Client的ACK之前的TCP連接稱為半連接（half-open connect），此時Server處於SYN_RCVD狀態，當收到ACK後，Server轉入ESTABLISHED狀態。SYN攻擊就是Client在短時間內偽造大量不存在的IP地址，並向Server不斷地發送SYN包，Server回復確認包，並等待Client的確認，由於源地址是不存在的，因此，Server需要不斷重發直至超時，這些偽造的SYN包將產時間占用未連接隊列，導致正常的SYN請求因為隊列滿而被丟棄，從而引起網絡堵塞甚至系統癱瘓。 SYN攻擊時一種典型的DDOS攻擊，檢測SYN攻擊的方式非常簡單，即當Server上有大量半連接狀態且源IP地址是隨機的，則可以斷定遭到SYN攻擊了，使用如下命令可以讓之現行： #netstat -nap | grep SYN_RECV 22、四次揮手 三次握手耳熟能詳，所謂四次揮手（Four-Way Wavehand）即終止TCP連接，就是指斷開一個TCP連接時，需要客戶端和服務端總共發送4個包以確認連接的斷開。在socket編程中，這一過程由客戶端或服務端任一方執行close來觸發，整個流程所示TCP四次揮手 :

四次分手： 由於TCP連接是全雙工的，因此每個方向都必須單獨進行關閉。這個原則是當一方完成它的數據發送任務後就能發送一個FIN來終止這個方向的連接。收到一個 FIN只意味著這一方向上沒有數據流動，一個TCP連接在收到一個FIN後仍能發送數據。首先進行關閉的一方將執行主動關閉，而另一方執行被動關閉。 （1）客戶端A發送一個FIN，用來關閉客戶A到服務器B的數據傳送（報文段4）。 （2）服務器B收到這個FIN，它發回一個ACK，確認序號為收到的序號加1（報文段5）。和SYN一樣，一個FIN將占用一個序號。 （3）服務器B關閉與客戶端A的連接，發送一個FIN給客戶端A（報文段6）。 （4）客戶端A發回ACK報文確認，並將確認序號設置為收到序號加1（報文段7）。

由於TCP連接時全雙工的，因此，每個方向都必須要單獨進行關閉，這一原則是當一方完成數據發送任務後，發送一個FIN來終止這一方向的連接，收到一個FIN只是意味著這一方向上沒有數據流動了，即不會再收到數據了，但是在這個TCP連接上仍然能夠發送數據，直到這一方 （3）第三次揮手：Server發送一個FIN，用來關閉Server到Client的數據傳送，Server進入LAST_ACK狀態。 （4）第四次揮手：Client收到FIN後，Client進入TIME_WAIT狀態，接著發送一個ACK給Server，確認序號為收到序號+1，Server進入CLOSED狀態，完成四次揮手。 上面是一方主動關閉，另一方被動關閉的情況，實際中還會出現同時發起主動關閉的情況，具體流程同時揮手如下圖 ：

流程和狀態在上圖中已經很明了了，在此不再贅述，可以參考前面的四次揮手解析步驟。

註意】中斷連接端可以是Client端，也可以是Server端。 假設Client端發起中斷連接請求，也就是發送FIN報文。Server端接到FIN報文後，意思是說"我Client端沒有數據要發給你了"，但是如果你還有數據沒有發送完成，則不必急著關閉Socket，可以繼續發送數據。所以你先發送ACK，"告訴Client端，你的請求我收到了，但是我還沒準備好，請繼續你等我的消息"。這個時候Client端就進入FIN_WAIT狀態，繼續等待Server端的FIN報文。當Server端確定數據已發送完成，則向Client端發送FIN報文，"告訴Client端，好了，我這邊數據發完了，準備好關閉連接了"。Client端收到FIN報文後，"就知道可以關閉連接了，但是他還是不相信網絡，怕Server端不知道要關閉，所以發送ACK後進入TIME_WAIT狀態，如果Server端沒有收到ACK則可以重傳。“，Server端收到ACK後，"就知道可以斷開連接了"。Client端等待了2MSL後依然沒有收到回復，則證明Server端已正常關閉，那好，我Client端也可以關閉連接了。Ok，TCP連接就這樣關閉了！ 整個過程Client端所經歷的狀態如下：

而Server端所經歷的過程如下：

【註意】在TIME_WAIT狀態中，如果TCP client端最後一次發送的ACK丟失了，它將重新發送。TIME_WAIT狀態中所需要的時間是依賴於實現方法的。典型的值為30秒、1分鐘和2分鐘。等待之後連接正式關閉，並且所有的資源(包括端口號)都被釋放。 保活計時器： 設想有這樣的情況：客戶端已主動與服務器建立了TCP連接，但後來客戶端的主機突然出現故障。 通常設為2小時。若2小時沒有收到客戶端的數據，服務器就發送一個探測報文段，以後則每隔75分鐘發送一次。若一連發送10個探測報文段後仍無客戶端的響應，服務器就認為客戶端出現了故障，接著就關閉這個連接。

13.TCP釋放連接四次握手

（1）四次握手過程 　　假設主機A為客戶端，主機B為服務器，其釋放TCP連接的過程如下： 1） 關閉客戶端到服務器的連接：首先客戶端A發送一個FIN，用來關閉客戶到服務器的數據傳送，然後等待服務器的確認。其中終止標誌位FIN=1，序列號seq=u 　 2） 服務器收到這個FIN，它發回一個ACK，確認號ack為收到的序號加1。
　3） 關閉服務器到客戶端的連接：也是發送一個FIN給客戶端。
　 4） 客戶段收到FIN後，並發回一個ACK報文確認，並將確認序號seq設置為收到序號加1。 首先進行關閉的一方將執行主動關閉，而另一方執行被動關閉。

　主機A發送FIN後，進入終止等待狀態， 服務器B收到主機A連接釋放報文段後，就立即給主機A發送確認，然後服務器B就進入close-wait狀態，此時TCP服務器進程就通知高層應用進程，因而從A到B的連接就釋放了。此時是“半關閉”狀態。即A不可以發送給B，但是B可以發送給A。
　　此時，若B沒有數據報要發送給A了，其應用進程就通知TCP釋放連接，然後發送給A連接釋放報文段，並等待確認。A發送確認後，進入time-wait，註意，此時TCP連接還沒有釋放掉，然後經過時間等待計時器設置的2MSL後，A才進入到close狀態。
（2）為什麽要等待2MSL呢?
MSL即Maximum Segment Lifetime，也就是最大報文生存時間，他是任何報文在網絡上存在的最長時間，超過這個時間報文將被丟棄。引用《TCP/IP詳解》中的話：“它(MSL)是任何報文段被丟棄前在網絡內的最長時間”。RFC 793中規定MSL為2分鐘，實際應用中常用的是30秒，1分鐘和2分鐘等。 TCP的TIME_WAIT狀態需要等待2MSL，當TCP的一端發起主動關閉，在發出最後一個ACK包後，即第3次握手完成後發送了第四次握手的ACK包後就進入了TIME_WAIT狀態，必須在此狀態上停留兩倍的MSL時間，等待2MSL時間主要目的是怕最後一個ACK包對方沒收到，那麽對方在超時後將重發第三次握手的FIN包，主動關閉端接到重發的FIN包後可以再發一個ACK應答包。在TIME_WAIT狀態時兩端的端口不能使用，要等到2MSL時間結束才可繼續使用。當連接處於2MSL等待階段時任何遲到的報文段都將被丟棄。不過在實際應用中可以通過設置SO_REUSEADDR選項達到不必等待2MSL時間結束再使用此端口。 概括原因如下： ①、為了保證A發送的最後一個ACK報文段能夠到達B。即最後這個確認報文段很有可能丟失，那麽B會超時重傳，然後A再一次確認，同時啟動2MSL計時器，如此下去。如果沒有等待時間，發送完確認報文段就立即釋放連接的話，B就無法重傳了（連接已被釋放，任何數據都不能出傳了），因而也就收不到確認，就無法按照步驟進入CLOSE狀態，即必須收到確認才能close。
②、防止“已失效的連接請求報文段”出現在連接中。經過2MSL，那些在這個連接持續的時間內，產生的所有報文段就可以都從網絡中消失。即在這個連接釋放的過程中會有一些無效的報文段滯留在樓閣結點，但是呢，經過2MSL這些無效報文段就肯定可以發送到目的地，不會滯留在網絡中。這樣的話，在下一個連接中就不會出現上一個連接遺留下來的請求報文段了。
可以看出：B結束TCP連接的時間比A早一點，因為B收到確認就斷開連接了，而A還得等待2MSL. （3）為什麽TCP釋放連接需要四次？ TCP建立連接要進行三次握手，而斷開連接要進行四次。這是由於TCP的半關閉造成的。因為TCP連接是全雙工的(即數據可在兩個方向上同時傳遞)所以進行關閉時每個方向上都要單獨進行關閉。這個單方向的關閉就叫半關閉。當一方完成它的數據發送任務，就發送一個FIN來向另一方通告將要終止這個方向的連接。 註意： 1）發送了FIN只是表示這端不能繼續發送數據(應用層不能再調用send發送)，但是還可以接收數據。收到一個 FIN只意味著這一方向上沒有數據流動，一個TCP連接在收到一個FIN後仍能發送數據，比如：如主機A收到主機B的FIN斷開TCP連接請求，只是表示主機B已經發送完數據，主機A收到FIN後作出應答，並終止這個方向的數據傳輸，此時處於半關閉狀態。但是主機A仍然可以發送數據的，只有當主機A發送完數據並發送FIN給主機B時，主機B才停止這個方向的數據傳輸，並關閉TCP連接。 2）在很多時候，TCP連接的斷開都會由TCP層自動進行，例如你CTRL+C終止你的程序，TCP連接依然會正常關閉，你可以寫代碼試試。

12.TCP建立連接三次握手

（1）、三次握手的過程 1）主機A向主機B發送TCP連接請求數據包，其中包含主機A的初始序列號seq(A)=x。（其中報文中同步標誌位SYN=1，ACK=0，表示這是一個TCP連接請求數據報文；序號seq=x，表明傳輸數據時的第一個數據字節的序號是x）；
2）主機B收到請求後，會發回連接確認數據包。（其中確認報文段中，標識位SYN=1，ACK=1，表示這是一個TCP連接響應數據報文，並含主機B的初始序列號seq(B)=y，以及主機B對主機A初始序列號的確認號ack(B)=seq(A)+1=x+1）
3）第三次，主機A收到主機B的確認報文後，還需作出確認，即發送一個序列號seq(A)=x+1；確認號為ack(A)=y+1的報文；

（2）為什麽需要第三次握手? 還要再發送一次確認是為了，防止已失效的連接請求報文段突然又傳到了B，因而產生錯誤。
已失效的報文段：正常情況下：A發出連接請求，但因為丟失了，故而不能收到B的確認。於是A重新發出請求，然後收到確認，建立連接，數據傳輸完畢後，釋放連接，A發了2個，一個丟掉，一個到達，沒有“已失效的報文段”
但是，某種情況下，A的第一個在某個節點滯留了，延誤到達，本來這是一個早已失效的報文段，但是在A發送第二個，並且得到B的回應，建立了連接以後，這個報文段竟然到達了，於是B就認為，A又發送了一個新的請求，於是發送確認報文段，同意建立連接，假若沒有三次的握手，那麽這個連接就建立起來了（有一個請求和一個回應），此時，A收到B的確認，但A知道自己並沒有發送建立連接的請求，因為不會理睬B的這個確認，於是呢，A也不會發送任何數據，而B呢卻以為新的連接建立了起來，一直等待A發送數據給自己，此時B的資源就被白白浪費了。但是采用三次握手的話，A就不發送確認，那麽B由於收不到確認，也就知道並沒有要求建立連接。 簡而言之：第三次握手，主機A發送一次確認是為了防止：如果客戶端遲遲沒有收到服務器返回的確認報文，這時他會放棄連接，重新啟動一條連接請求；但問題是：服務器不知客戶端沒收到，所以他會收到兩個連接請求，白白浪費了一條連接開銷。

11.TCP報文段首部格式：

在談及TCP建立連接和釋放連接過程，先來簡單認識一下TCP報文段首部格式的的幾個名詞（這裏只是簡單說明，具體請查看相關教程） 序列號seq：占4個字節，用來標記數據段的順序，TCP把連接中發送的所有數據字節都編上一個序號，第一個字節的編號由本地隨機產生；給字節編上序號後，就給每一個報文段指派一個序號；序列號seq就是這個報文段中的第一個字節的數據編號。
確認號ack：占4個字節，期待收到對方下一個報文段的第一個數據字節的序號；序列號表示報文段攜帶數據的第一個字節的編號；而確認號指的是期望接收到下一個字節的編號；因此當前報文段最後一個字節的編號+1即為確認號。
確認ACK：占1位，僅當ACK=1時，確認號字段才有效。ACK=0時，確認號無效
同步SYN：連接建立時用於同步序號。當SYN=1，ACK=0時表示：這是一個連接請求報文段。若同意連接，則在響應報文段中使得SYN=1，ACK=1。因此，SYN=1表示這是一個連接請求，或連接接受報文。SYN這個標誌位只有在TCP建產連接時才會被置1，握手完成後SYN標誌位被置0。
終止FIN：用來釋放一個連接。FIN=1表示：此報文段的發送方的數據已經發送完畢，並要求釋放運輸連接 PS：ACK、SYN和FIN這些大寫的單詞表示標誌位，其值要麽是1，要麽是0；ack、seq小寫的單詞表示序號。

上圖中有幾個字段需要重點介紹下：
（1）序號：Seq序號，占32位，用來標識從TCP源端向目的端發送的字節流，發起方發送數據時對此進行標記。
Sequence number(順序號碼)
（2）確認序號：Ack序號，占32位，只有ACK標誌位為1時，確認序號字段才有效，Ack=Seq+1。
Acknowledge number(確認號碼)；
（3）標誌位：共6個，即URG、ACK、PSH、RST、SYN、FIN等，具體含義如下：

TCP(Transmission Control Protocol)　傳輸控制協議 TCP是主機對主機層的傳輸控制協議，提供可靠的連接服務，采用三次握手確認建立一個連接:

位碼即tcp標誌位,有6種標示:

（1）SYN(synchronous建立聯機)：發起一個新連接。 SYN(SYNchronization) ：在連接建立時用來同步序號。

SYN(synchronous建立聯機) SYN：同步序列編號（Synchronize Sequence Numbers）。

（2）ACK：(acknowledgement 確認)確認序號有效。
TCP協議規定，只有ACK=1時有效，也規定連接建立後所有發送的報文的ACK必須為1
（3）URG(urgent緊急)：緊急指針（urgent pointer）有效。
（4）PSH(push傳送)：接收方應該盡快將這個報文交給應用層。
（5）RST(reset重置)：重置連接。
（6）FIN：(finish結束)釋放一個連接。當 FIN = 1 時，表明此報文段的發送方的數據已經發送完畢，並要求釋放連接。

需要註意的是：
（A）不要將確認序號Ack與標誌位中的ACK搞混了。
（B）確認方Ack=發起方Seq+1，兩端配對。
當SYN=1而ACK=0時，表明這是一個連接請求報文。對方若同意建立連接，則應在響應報文中使SYN=1和ACK=1. 因此, SYN置1就表示這是一個連接請求或連接接受報文。

對TCP協議握手的理解（轉）