tcp(傳輸層)
TCP（Transmission Control Protocol 傳輸控制協(xié)議）是一種面向連接的、可靠的、基于字節(jié)流的傳輸層通信協(xié)議，由IETF的RFC 793定義。在簡(jiǎn)化的計(jì)算機(jī)網(wǎng)絡(luò)OSI模型中，它完成第四層傳輸層所指定的功能，用戶數(shù)據(jù)報(bào)協(xié)議（UDP）是同一層內(nèi) 另一個(gè)重要的傳輸協(xié)議。在因特網(wǎng)協(xié)議族（Internet protocol suite）中，TCP層是位于IP層之上，應(yīng)用層之下的中間層。不同主機(jī)的應(yīng)用層之間經(jīng)常需要可靠的、像管道一樣的連接，但是IP層不提供這樣的流機(jī)制，而是提供不可靠的包交換。
應(yīng)用層向TCP層發(fā)送用于網(wǎng)間傳輸?shù)摹⒂?位字節(jié)表示的數(shù)據(jù)流，然后TCP把數(shù)據(jù)流分區(qū)成適當(dāng)長(zhǎng)度的報(bào)文段（通常受該計(jì)算機(jī)連接的網(wǎng)絡(luò)的數(shù)據(jù)鏈路層的最大傳輸單元（ MTU）的限制）。之后TCP把結(jié)果包傳給IP層，由它來(lái)通過(guò)網(wǎng)絡(luò)將包傳送給接收端實(shí)體 的TCP層。TCP為了保證不發(fā)生丟包，就給每個(gè)包一個(gè)序號(hào)，同時(shí)序號(hào)也保證了傳送到接收端實(shí)體的包的按序接收。然后接收端實(shí)體對(duì)已成功收到的包發(fā)回一個(gè)相應(yīng)的確認(rèn)（ACK）；如果發(fā)送端實(shí)體在合理的往返時(shí)延（RTT）內(nèi)未收到確認(rèn)，那么對(duì)應(yīng)的數(shù)據(jù)包就被假設(shè)為已丟失將會(huì)被進(jìn)行重傳。TCP用一個(gè)校驗(yàn)和函數(shù)來(lái)檢驗(yàn)數(shù)據(jù)是否有錯(cuò)誤；在發(fā)送和接收時(shí)都要計(jì)算校驗(yàn)和。
三次握手
TCP是因特網(wǎng)中的傳輸層協(xié)議，使用三次握手協(xié)議建立連接。當(dāng)主動(dòng)方發(fā)出SYN連接請(qǐng)求后，等待對(duì)方回答SYN+ACK ，并最終對(duì)對(duì)方的 SYN 執(zhí)行 ACK 確認(rèn)。這種建立連接的方法可以防止產(chǎn)生錯(cuò)誤的連接，TCP使用的流量控制協(xié)議是可變大小的滑動(dòng)窗口協(xié)議。 TCP三次握手的過(guò)程如下：
- 客戶端發(fā)送SYN（SEQ=x）報(bào)文給服務(wù)器端，進(jìn)入SYN_SEND狀態(tài)。
- 服務(wù)器端收到SYN報(bào)文，回應(yīng)一個(gè)SYN （SEQ=y）ACK(ACK=x+1）報(bào)文，進(jìn)入SYN_RECV狀態(tài)。
- 客戶端收到服務(wù)器端的SYN報(bào)文，回應(yīng)一個(gè)ACK(ACK=y+1）報(bào)文，進(jìn)入Established狀態(tài)。
連接成功
連接成功之后雙方即可互相傳輸字節(jié)流,并隨時(shí)可關(guān)閉連接,傳輸?shù)臄?shù)據(jù)有以下特性
-
傳輸?shù)臄?shù)據(jù)被tcp分割成了最適合發(fā)送的數(shù)據(jù)塊 傳遞給ip協(xié)議,這個(gè)發(fā)送數(shù)據(jù)稱為 報(bào)文段 或 段
-
tcp作為可靠性連接,每次發(fā)送數(shù)據(jù)段,會(huì)啟動(dòng)一個(gè)定時(shí)器,每次接收數(shù)據(jù)段,會(huì)發(fā)送一次確認(rèn),如果定時(shí)器沒(méi)有及時(shí)收到確認(rèn),則會(huì)重發(fā)數(shù)據(jù)
-
TCP將保持它首部和數(shù)據(jù)的檢驗(yàn)和。這是一個(gè)端到端的檢驗(yàn)和，目的是檢測(cè)數(shù)據(jù)在傳輸過(guò)程中的任何變化。如果收到段的檢驗(yàn)和有差錯(cuò)，TCP將丟棄這個(gè)報(bào)文段和不確認(rèn)收到此報(bào)文段（希望發(fā)端超時(shí)并重發(fā)）。
-
兩個(gè)應(yīng)用程序通過(guò)TCP連接交換8bit字節(jié)構(gòu)成的字節(jié)流。TCP不在字節(jié)流中插入記錄標(biāo)識(shí)符。我們將這稱為字節(jié)流服務(wù)（bytestreamservice）。如果一方的應(yīng)用程序先傳10字節(jié)，又傳20字節(jié)，再傳50字節(jié)，連接的另一方將無(wú)法了解發(fā)方每次發(fā)送了多少字節(jié)。只要自己的接收緩存沒(méi)有塞滿，TCP 接收方將有多少就收多少。一端將字節(jié)流放到TCP連接上，同樣的字節(jié)流將出現(xiàn)在TCP連接的另一端。
四次揮手
建立一個(gè)連接需要三次握手，而終止一個(gè)連接要經(jīng)過(guò)四次揮手，這是由TCP的半關(guān)閉（half-close）造成的。具體過(guò)程如下所示。
- 某個(gè)應(yīng)用進(jìn)程首先調(diào)用close，稱該端執(zhí)行“主動(dòng)關(guān)閉”（active close）。該端的TCP于是發(fā)送一個(gè)FIN分節(jié)，表示數(shù)據(jù)發(fā)送完畢。
- 接收到這個(gè)FIN的對(duì)端執(zhí)行 “被動(dòng)關(guān)閉”（passive close），這個(gè)FIN由TCP確認(rèn)。
- 注意：FIN的接收也作為一個(gè)文件結(jié)束符（end-of-file）傳遞給接收端應(yīng)用進(jìn)程，放在已排隊(duì)等候該應(yīng)用進(jìn)程接收的任何其他數(shù)據(jù)之后，因?yàn)椋現(xiàn)IN的接收意味著接收端應(yīng)用進(jìn)程在相應(yīng)連接上再無(wú)額外數(shù)據(jù)可接收。
- 一段時(shí)間后，接收到這個(gè)文件結(jié)束符的應(yīng)用進(jìn)程將調(diào)用close關(guān)閉它的套接字。這導(dǎo)致它的TCP也發(fā)送一個(gè)FIN。
- 接收這個(gè)最終FIN的原發(fā)送端TCP（即執(zhí)行主動(dòng)關(guān)閉的那一端）確認(rèn)這個(gè)FIN。 既然每個(gè)方向都需要一個(gè)FIN和一個(gè)ACK，因此通常需要4個(gè)分節(jié)。
“通常”是指，某些情況下，步驟1的FIN隨數(shù)據(jù)一起發(fā)送，另外，步驟2和步驟3發(fā)送的分節(jié)都出自執(zhí)行被動(dòng)關(guān)閉那一端，有可能被合并成一個(gè)分節(jié)。 在步驟2與步驟3之間，從執(zhí)行被動(dòng)關(guān)閉一端到執(zhí)行主動(dòng)關(guān)閉一端流動(dòng)數(shù)據(jù)是可能的，這稱為“半關(guān)閉”（half-close）。 當(dāng)一個(gè)Unix進(jìn)程無(wú)論自愿地（調(diào)用exit或從main函數(shù)返回）還是非自愿地（收到一個(gè)終止本進(jìn)程的信號(hào)）終止時(shí)，所有打開(kāi)的描述符都被關(guān)閉，這也導(dǎo)致仍然打開(kāi)的任何TCP連接上也發(fā)出一個(gè)FIN。 無(wú)論是客戶還是服務(wù)器，任何一端都可以執(zhí)行主動(dòng)關(guān)閉。通常情況是，客戶執(zhí)行主動(dòng)關(guān)閉，但是某些協(xié)議，例如，HTTP/1.0卻由服務(wù)器執(zhí)行主動(dòng)關(guān)閉。
php中的tcp
php可通過(guò)socket函數(shù),swoole擴(kuò)展,stream流函數(shù)進(jìn)行創(chuàng)建tcp協(xié)議的socket,綁定網(wǎng)卡端口,進(jìn)行tcp服務(wù)端/客戶端操作
在php中,我們并不需要了解tcp的握手/揮手,我們只需要知道ip:port能連接/創(chuàng)建 一個(gè)tcp服務(wù)端/客戶端就行了
使用php的socket,我們可以直接發(fā)送字符串,接收的也是字符串,其他一切都是語(yǔ)言,操作系統(tǒng)所需要做的事,
我們只需要處理好字符串的完整性,例如我們使用php做tcp服務(wù)端
- 客戶端連接成功后,發(fā)送了一個(gè)"easyswoole是一個(gè)非常好的swoole框架"的字符串
- 而服務(wù)端每次只接收9個(gè)字節(jié),那第一次獲取只會(huì)接收到"easyswool"的殘缺字符串,需要繼續(xù)獲取數(shù)據(jù)
其他
可自行搜索詳細(xì)理解