TCP標志位,有6種標示：SYN(synchronous建立聯(lián)機) ，ACK(acknowledgement 確認) ，PSH(push傳送)，F(xiàn)IN(finish結束) ，RST(reset重置)， URG(urgent緊急)
Sequence number(順序號碼) ，Acknowledge number(確認號碼),在上面我們已經(jīng)詳細說明！下圖是工作原理圖：
三次握手：
第一次握手：建立連接時，主機A發(fā)送SYN包(syn=m)到服務器，并進入SYN_SEND狀態(tài)，等待主機B確認
第二次握手：主機B收到SYN包，必須確認主機A的SYN（ACK=m+1），同時自己也發(fā)送一個SYN包（SYN=n），即SYN+ACK包，此時主機B進入SYN_RECV狀態(tài)
第三次握手：主機A收到主機B的SYN＋ACK包，向主機B發(fā)送確認包ACK(ACK=n+1)，此包發(fā)送完畢，主機A和主機B進入ESTABLISHED狀態(tài)，完成三次握手
四次斷開：
當主機A完成數(shù)據(jù)傳輸后,將控制位FIN置1,提出停止TCP連接的請求
主機B收到FIN后對其作出響應,確認這一方向上的TCP連接將關閉,將ACK置1
由主機B端再提出反方向的關閉請求,將FIN置1
主機A對主機B的請求進行確認,將ACK置1,雙方向的關閉結束
二、http請求模型和工作模式
上 圖是http的請求模式，http的工作模式有三種：prefork、worker、event，下面介紹prefork和worker的工作模 式，prefork模式使用多個子進程，每個子進程只有一個線程。每個進程在某個確定的時間只能維持一個連接。在大多數(shù)平臺上，Prefork MPM在效率上要比Worker MPM要高，但是內(nèi)存使用大得多。prefork的無線程設計在某些情況下將比worker更有優(yōu)勢：它可以使用那些沒有處理好線程安全的第三方模塊，并 且對于那些線程調(diào)試困難的平臺而言，它也更容易調(diào)試一些。perfork模式原理圖：
worker 模式使用多個子進程，每個子進程有多個線程。每個線程在某個確定的時間只能維持一個連接。通常來說，在一個高流量的HTTP服務器 上，Worker MPM是個比較好的選擇，因為Worker MPM的內(nèi)存使用比Prefork MPM要低得多。但worker MPM也由不完善的地方，如果一個線程崩潰，整個進程就會連同其所有線程一起”死掉”.由于線程共享內(nèi)存空間，所以一個程序在運行時必須被系統(tǒng)識別為”每 個線程都是安全的”。下面是worker的工作原理圖：
總的來說，prefork方式速度要稍高于worker，然而它需要的cpu和memory資源也稍多于woker。
TCP
TCP（Transmission Control Protocol，傳輸控制協(xié)議）是面向連接的協(xié)議，也就是說，在收發(fā)數(shù)據(jù)前，必須和對方建立可靠的連接。一個TCP連接必須要經(jīng)過三次“對話”才能建立起來，其中的過程非常復雜，只簡單的描述下這三次對話的簡單過程：主機A向主機B發(fā)出連接請求數(shù)據(jù)包：“我想給你發(fā)數(shù)據(jù)，可以嗎？”，這是第一次對話；主機B向主機A發(fā)送同意連接和要求同步（同步就是兩臺主機一個在發(fā)送，一個在接收，協(xié)調(diào)工作）的數(shù)據(jù)包：“可以，你什么時候發(fā)？”，這是第二次對話；主機A再發(fā)出一個數(shù)據(jù)包確認主機B的要求同步：“我現(xiàn)在就發(fā)，你接著吧！”，這是第三次對話。三次“對話”的目的是使數(shù)據(jù)包的發(fā)送和接收同步，經(jīng)過三次“對話”之后，主機A才向主機B正式發(fā)送數(shù)據(jù)。
UDP
UDP（User Data Protocol，用戶數(shù)據(jù)報協(xié)議）
（1） UDP是一個非連接的協(xié)議，傳輸數(shù)據(jù)之前源端和終端不建立連接，當它想傳送時就簡單地去抓取來自應用程序的數(shù)據(jù)，并盡可能快地把它扔到網(wǎng)絡上。在發(fā)送端，UDP傳送數(shù)據(jù)的速度僅僅是受應用程序生成數(shù)據(jù)的速度、計算機的能力和傳輸帶寬的限制；在接收端，UDP把每個消息段放在隊列中，應用程序每次從隊列中讀一個消息段。
（2） 由于傳輸數(shù)據(jù)不建立連接，因此也就不需要維護連接狀態(tài)，包括收發(fā)狀態(tài)等，因此一臺服務機可同時向多個客戶機傳輸相同的消息。
（3） UDP信息包的標題很短，只有8個字節(jié)，相對于TCP的20個字節(jié)信息包的額外開銷很小。
（4） 吞吐量不受擁擠控制算法的調(diào)節(jié)，只受應用軟件生成數(shù)據(jù)的速率、傳輸帶寬、源端和終端主機性能的限制。
（5）UDP使用盡最大努力交付，即不保證可靠交付，因此主機不需要維持復雜的鏈接狀態(tài)表（這里面有許多參數(shù)）。
（6）UDP是面向報文的。發(fā)送方的UDP對應用程序交下來的報文，在添加首部后就向下交付給IP層。既不拆分，也不合并，而是保留這些報文的邊界，因此，應用程序需要選擇合適的報文大小。
我們經(jīng)常使用“ping”命令來測試兩臺主機之間TCP/IP通信是否正常，其實“ping”命令的原理就是向?qū)Ψ街鳈C發(fā)送UDP數(shù)據(jù)包，然后對方主機確認收到數(shù)據(jù)包，如果數(shù)據(jù)包是否到達的消息及時反饋回來，那么網(wǎng)絡就是通的。
HTTPS 與HTTP
HTTPS是一個安全通信通道，它基于HTTP開發(fā)，用于在客戶計算機和服務器之間交換信息。它使用安全套接字層(SSL)進行信息交換，簡單來說它是HTTP的安全版。它是由Netscape開發(fā)并內(nèi)置于其瀏覽器中，用于對數(shù)據(jù)進行壓縮和解壓操作，并返回網(wǎng)絡上傳送回的結果。HTTPS實際上應用了Netscape的安全套接字層（SSL）作為HTTP應用層的子層。
區(qū)別：
第一：HTTPS協(xié)議需要到CA申請證書，一般免費證書很少，需要交費。
第二：HTTP是超文本傳輸協(xié)議，信息是明文傳輸，HTTPS則是具有安全性的SSL加密傳輸協(xié)議。
所以在 TCP端口發(fā)送文件需要 http驗證：
如下這段代碼就可以完整發(fā)送：文章來源：http://www.zghlxwxcb.cn/news/detail-708900.html
POST http://localhost:8081/WebAPI/TestThis.ashx HTTP/1.1
Content-Type: text/plain
Host: localhost:8081
Content-Length: 29
00 00 00 00 00 04 01 02 01 01
文章來源地址http://www.zghlxwxcb.cn/news/detail-708900.html
到了這里，關于淺談Http協(xié)議、TCP協(xié)議（轉載）的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關文章，希望大家以后多多支持TOY模板網(wǎng)！
