HTTP協議

HTTP協議是Hyper Text Transfer Protocol（超文本傳輸協議）的縮寫,是用于從萬維網服務器傳輸超文本到本地瀏覽器的傳送協議。HTTP是基于TCP/IP協議通信協議來傳遞數據（HTML文件, 圖片文件, 查詢結果等）。它不涉及數據包（packet）傳輸，主要規定了客戶端和服務器之間的通信格式，默認使用80端口。

Http的特點

1. 簡單快速：客戶向服務器請求服務時，只需傳送請求方法和路徑。由于HTTP協議簡單，使得HTTP服務器的程序規模小，因而通信速度很快。
2. 靈活：HTTP允許傳輸任意類型的數據對象。
3. 無連接：無連接的含義是限制每次連接只處理一個請求。服務器處理完客戶的請求，并收到客戶的應答后，即斷開連接。采用這種方式可以節省傳輸時間。
4. 無狀態：HTTP協議是無狀態的，HTTP 協議自身不對請求和響應之間的通信狀態進行保存。任何兩次請求之間都沒有依賴關系。直觀地說，就是每個請求都是獨立的，與前面的請求和后面的請求都是沒有直接聯系的。協議本身并不保留之前一切的請求或 響應報文的信息。這是為了更快地處理大量事務，確保協議的可伸縮性，而特意把 HTTP 協議設計成如此簡單的。

Http報文

Http報文包括請求報文和響應報文兩大部分，其中請求報文由請求行（request line）、請求頭（header）、空行和請求體四個部分組成。而響應報文由狀態行、響應頭部、空行和響應體四個部分組成。接下來我們了解下請求報文的各個部分及其作用。

1.請求行，用來說明請求類型,要訪問的資源以及所使用的HTTP版本。

POST  /chapter17/user.html HTTP/1.1

POST代表請求方法，/chapter17/user.html表示URI，HTTP/1.1代表協議和協議的版本。

2.請求頭由關鍵字/值對組成，每行一對，關鍵字和值用英文冒號“:”分隔。

請求頭部通知服務器有關于客戶端請求的信息。它包含許多有關的客戶端環境和請求正文的有用信息。其中比如：
Host表示主機名，虛擬主機；
Connection，HTTP/1.1增加的，使用keepalive，即持久連接，一個連接可以發多個請求；
User-Agent，請求發出者，兼容性以及定制化需求。

3.最后一個請求頭之后是一個空行，這個行非常重要，它表示請求頭已經結束，接下來的是請求正文。

4.請求體，可以承載多個請求參數的數據

name=tom&password=1234&realName=tomson

HTTP請求方法

GET請求指定的頁面信息，并返回實體主體。
HEAD類似于get請求，只不過返回的響應中沒有具體的內容，用于獲取報頭
POST向指定資源提交數據進行處理請求（例如提交表單或者上傳文件）。數據被包含在請求體中。
PUT從客戶端向服務器傳送的數據取代指定的文檔的內容。
DELETE請求服務器刪除指定的頁面。

GET與POST區別

GET在瀏覽器回退時是無害的，而POST會再次提交請求
GET請求會被瀏覽器主動緩存，而POST不會，除非手動設置
GET請求參數會被完整保留在瀏覽器歷史記錄里，而POST中的參數不會被保留
GET請求在URL中傳送的參數是有長度限制的，而POST沒有限制
GET參數通過URL傳遞，POST放在Request body中

Http狀態碼

狀態代碼有三位數字組成，第一個數字定義了響應的類別，共分五種類別:

• 1xx：指示信息--表示請求已接收，繼續處理
• 2xx：成功--表示請求已被成功接收、理解、接受
• 3xx：重定向--要完成請求必須進行更進一步的操作
• 4xx：客戶端錯誤--請求有語法錯誤或請求無法實現
• 5xx：服務器端錯誤--服務器未能實現合法的請求

持久連接

為什么需要持久連接

HTTP協議的初始版本中，每進行一次HTTP通信就要斷開一次TCP連接。以當年的通信情況來說，因為都是些容量很小的文本傳輸，所以即使這樣也沒有多大問題。可隨著 HTTP 的 普及，文檔中包含大量圖片的情況多了起來。比如，使用瀏覽器瀏覽一個包含多張圖片的 HTML 頁面時，在發送請求訪問 HTML 頁面資源的同時，也會請 求該 HTML 頁面里包含的其他資源。因此，每次的請求都會造成無謂的 TCP 連接建立和斷開，增加通信量的 開銷。

持久連接的特點

為解決上述 TCP 連接的問題，HTTP/1.1 和一部分的 HTTP/1.0 想出了持久連接（HTTP Persistent Connections，也稱為 HTTP keep-alive 或 HTTP connection reuse）的方法。持久連接的特點是，只要任意一端沒有明確提出斷開連接，則保持TCP連接狀態。
持久連接的好處在于減少了 TCP 連接的重復建立和斷開所造成的額外開銷，減輕了服務器端的負載。另外， 減少開銷的那部分時間，使 HTTP 請求和響應能夠更早地結束，這樣 Web 頁面的顯示速度也就相應提高了。
在 HTTP/1.1 中，所有的連接默認都是持久連接，但在 HTTP/1.0 內并未標準化。雖然有一部分服務器通過非 標準的手段實現了持久連接，但服務器端不一定能夠支持持久連接。毫無疑問，除了服務器端，客戶端也需 要支持持久連接。

管線化

持久連接使得多數請求以管線化（pipelining）方式發送成為可能。從前發送請求后需等待并收到響應，才能 發送下一個請求。管線化技術出現后，不用等待響應亦可直接發送下一個請求。
這樣就能夠做到同時并行發送多個請求，而不需要一個接一個地等待響應了。通俗地講，請求打包一次傳輸過去，響應打包一次傳遞回來。管線化的前提是在持久連接下。
假如當請求一個包含 10 張圖片的 HTML Web 頁面，與挨個連接相比，用持久連接可以讓請求更快結束。 而管線化技術則比持久連接還要快。請求數越多，時間差就越明顯。客戶端需要請求這十個資源。以前的做法是，在同一個TCP連接里面，先發送A請求，然后等待服務器做出回應，收到后再發出B請求，以此類推，而管道機制則是允許瀏覽器同時發出這十個請求，但是服務器還是按照順序，先回應A請求，完成后再回應B請求。

HTTPS工作原理

什么是HTTPS

HTTPS是在HTTP上建立SSL加密層，并對傳輸數據進行加密，是HTTP協議的安全版。
HTTPS主要作用是：

1. 對數據進行加密，并建立一個信息安全通道，來保證傳輸過程中的數據安全;
2. 對網站服務器進行真實身份認證。

為什么需要HTTPS

在HTTP協議中有可能存在信息竊取或身份偽裝等安全問題。使用HTTPS通信機制可以有效地防止這些問題。
HTTP協議存在的哪些問題：

• 通信使用明文（不加密），內容可能被竊聽
  由于HTTP本身不具備加密的功能，所以也無法做到對通信整體（使用HTTP協議通信的請求和響應的內容）進行加密。即，HTTP報文使用明文（指未經過加密的報文）方式發送。
  HTTP明文協議的缺陷是導致數據泄露、數據篡改、流量劫持、釣魚攻擊等安全問題的重要原因。HTTP協議無法加密數據，所有通信數據都在網絡中明文“裸奔”。通過網絡的嗅探設備及一些技術手段，就可還原HTTP報文內容。
• 無法證明報文的完整性，所以可能遭篡改
  所謂完整性是指信息的準確度。若無法證明其完整性，通常也就意味著無法判斷信息是否準確。由于HTTP協議無法證明通信的報文完整性，因此，在請求或響應送出之后直到對方接收之前的這段時間內，即使請求或響應的內容遭到篡改，也沒有辦法獲悉。
  換句話說，沒有任何辦法確認，發出的請求/響應和接收到的請求/響應是前后相同的。
• 不驗證通信方的身份，因此有可能遭遇偽裝
  HTTP協議中的請求和響應不會對通信方進行確認。在HTTP協議通信時，由于不存在確認通信方的處理步驟，任何人都可以發起請求。另外，服務器只要接收到請求，不管對方是誰都會返回一個響應（但也僅限于發送端的IP地址和端口號沒有被Web服務器設定限制訪問的前提下）

HTTP協議無法驗證通信方身份，任何人都可以偽造虛假服務器欺騙用戶，實現“釣魚欺詐”，用戶無法察覺。
反觀HTTPS協議，它比HTTP協議相比多了以下優勢:

• 數據隱私性：內容經過對稱加密，每個連接生成一個唯一的加密密鑰
• 數據完整性：內容傳輸經過完整性校驗
• 身份認證：第三方無法偽造服務端（客戶端）身份

HTTPS如何解決HTTP上述問題?

HTTPS并非是應用層的一種新協議。只是HTTP通信接口部分用SSL和TLS協議代替而已。

通常，HTTP直接和TCP通信。當使用SSL時，則演變成先和SSL通信，再由SSL和TCP通信了。簡言之，所謂HTTPS，其實就是身披SSL協議這層外殼的HTTP。
在采用SSL后，HTTP就擁有了HTTPS的加密、證書和完整性保護這些功能。也就是說HTTP加上加密處理和認證以及完整性保護后即是HTTPS。

HTTPS 協議的主要功能基本都依賴于 TLS/SSL 協議，TLS/SSL 的功能實現主要依賴于三類基本算法：散列函數 、對稱加密和非對稱加密，其利用非對稱加密實現身份認證和密鑰協商，對稱加密算法采用協商的密鑰對數據加密，基于散列函數驗證信息的完整性。

1.解決內容可能被竊聽的問題——加密

方法1.對稱加密
這種方式加密和解密同用一個密鑰。加密和解密都會用到密鑰。沒有密鑰就無法對密碼解密，反過來說，任何人只要持有密鑰就能解密了。

以對稱加密方式加密時必須將密鑰也發給對方。可究竟怎樣才能安全地轉交？在互聯網上轉發密鑰時，如果通信被監聽那么密鑰就可會落人攻擊者之手，同時也就失去了加密的意義。另外還得設法安全地保管接收到的密鑰。

方法2.非對稱加密
公開密鑰加密使用一對非對稱的密鑰。一把叫做私有密鑰，另一把叫做公開密鑰。顧名思義，私有密鑰不能讓其他任何人知道，而公開密鑰則可以隨意發布，任何人都可以獲得。

使用公開密鑰加密方式，發送密文的一方使用對方的公開密鑰進行加密處理，對方收到被加密的信息后，再使用自己的私有密鑰進行解密。利用這種方式，不需要發送用來解密的私有密鑰，也不必擔心密鑰被攻擊者竊聽而盜走。
非對稱加密的特點是信息傳輸一對多，服務器只需要維持一個私鑰就能夠和多個客戶端進行加密通信。

這種方式有以下缺點：
公鑰是公開的，所以針對私鑰加密的信息，黑客截獲后可以使用公鑰進行解密，獲取其中的內容；
公鑰并不包含服務器的信息，使用非對稱加密算法無法確保服務器身份的合法性，存在中間人攻擊的風險，服務器發送給客戶端的公鑰可能在傳送過程中被中間人截獲并篡改；
使用非對稱加密在數據加密解密過程需要消耗一定時間，降低了數據傳輸效率；

方法3.對稱加密+非對稱加密(HTTPS采用這種方式)
使用對稱密鑰的好處是解密的效率比較快，使用非對稱密鑰的好處是可以使得傳輸的內容不能被破解，因為就算你攔截到了數據，但是沒有對應的私鑰，也是不能破解內容的。就比如說你搶到了一個保險柜，但是沒有保險柜的鑰匙也不能打開保險柜。那我們就將對稱加密與非對稱加密結合起來,充分利用兩者各自的優勢，在交換密鑰環節使用非對稱加密方式，之后的建立通信交換報文階段則使用對稱加密方式。

具體做法是：發送密文的一方使用對方的公鑰進行加密處理“對稱的密鑰”，然后對方用自己的私鑰解密拿到“對稱的密鑰”，這樣可以確保交換的密鑰是安全的前提下，使用對稱加密方式進行通信。所以，HTTPS采用對稱加密和非對稱加密兩者并用的混合加密機制。

2.解決報文可能遭篡改問題——數字簽名

網絡傳輸過程中需要經過很多中間節點，雖然數據無法被解密，但可能被篡改，那如何校驗數據的完整性呢？----校驗數字簽名。
數字簽名有兩種功效：

• 能確定消息確實是由發送方簽名并發出來的，因為別人假冒不了發送方的簽名。
• 數字簽名能確定消息的完整性,證明數據是否未被篡改過。

數字簽名如何生成:

將一段文本先用Hash函數生成消息摘要，然后用發送者的私鑰加密生成數字簽名，與原文文一起傳送給接收者。接下來就是接收者校驗數字簽名的流程了。
校驗數字簽名流程：

接收者只有用發送者的公鑰才能解密被加密的摘要信息，然后用HASH函數對收到的原文產生一個摘要信息，與上一步得到的摘要信息對比。如果相同，則說明收到的信息是完整的，在傳輸過程中沒有被修改，否則說明信息被修改過，因此數字簽名能夠驗證信息的完整性。

假設消息傳遞在Kobe，James兩人之間發生。James將消息連同數字簽名一起發送給Kobe，Kobe接收到消息后，通過校驗數字簽名，就可以驗證接收到的消息就是James發送的。當然，這個過程的前提是Kobe知道James的公鑰。問題的關鍵的是，和消息本身一樣，公鑰不能在不安全的網絡中直接發送給Kobe,或者說拿到的公鑰如何證明是James的。

此時就需要引入了證書頒發機構（Certificate Authority，簡稱CA），CA數量并不多，Kobe客戶端內置了所有受信任CA的證書。CA對James的公鑰（和其他信息）數字簽名后生成證書。

3.解決通信方身份可能被偽裝的問題——數字證書

數字證書認證機構處于客戶端與服務器雙方都可信賴的第三方機構的立場上。
我們來介紹一下數字證書認證機構的業務流程：

• 服務器的運營人員向第三方機構CA提交公鑰、組織信息、個人信息(域名)等信息并申請認證;
• CA通過線上、線下等多種手段驗證申請者提供信息的真實性，如組織是否存在、企業是否合法，是否擁有域名的所有權等;
• 如信息審核通過，CA會向申請者簽發認證文件-證書。證書包含以下信息：申請者公鑰、申請者的組織信息和個人信息、簽發機構 CA的信息、有效時間、證書序列號等信息的明文，同時包含一個簽名。 其中簽名的產生算法：首先，使用散列函數計算公開的明文信息的信息摘要，然后，采用 CA的私鑰對信息摘要進行加密，密文即簽名;
• 客戶端 Client 向服務器 Server 發出請求時，Server 返回證書文件;
• 客戶端 Client 讀取證書中的相關的明文信息，采用相同的散列函數計算得到信息摘要，然后，利用對應 CA的公鑰解密簽名數據，對比證書的信息摘要，如果一致，則可以確認證書的合法性，即服務器的公開密鑰是值得信賴的。
• 客戶端還會驗證證書相關的域名信息、有效時間等信息; 客戶端會內置信任CA的證書信息(包含公鑰)，如果CA不被信任，則找不到對應 CA的證書，證書也會被判定非法。

HTTPS工作流程

1. Client發起一個HTTPS（比如https://juejin.im/user/5a9a9cdcf265da238b7d771c）的請求，根據RFC2818的規定，Client知道需要連接Server的443（默認）端口。
2. Server把事先配置好的公鑰證書（public key certificate）返回給客戶端。
3. Client驗證公鑰證書：比如是否在有效期內，證書的用途是不是匹配Client請求的站點，是不是在CRL吊銷列表里面，它的上一級證書是否有效，這是一個遞歸的過程，直到驗證到根證書（操作系統內置的Root證書或者Client內置的Root證書）。如果驗證通過則繼續，不通過則顯示警告信息。
4. Client使用偽隨機數生成器生成加密所使用的對稱密鑰，然后用證書的公鑰加密這個對稱密鑰，發給Server。
5. Server使用自己的私鑰（private key）解密這個消息，得到對稱密鑰。至此，Client和Server雙方都持有了相同的對稱密鑰。
6. Server使用對稱密鑰加密“明文內容A”，發送給Client。
7. Client使用對稱密鑰解密響應的密文，得到“明文內容A”。
8. Client再次發起HTTPS的請求，使用對稱密鑰加密請求的“明文內容B”，然后Server使用對稱密鑰解密密文，得到“明文內容B”。

HTTP 與 HTTPS 的區別

• HTTP 是明文傳輸協議，HTTPS 協議是由 SSL+HTTP 協議構建的可進行加密傳輸、身份認證的網絡協議，比 HTTP 協議安全。
• HTTPS比HTTP更加安全，對搜索引擎更友好，利于SEO,谷歌、百度優先索引HTTPS網頁;
• HTTPS需要用到SSL證書，而HTTP不用;
• HTTPS標準端口443，HTTP標準端口80;
• HTTPS基于傳輸層，HTTP基于應用層;
• HTTPS在瀏覽器顯示綠色安全鎖，HTTP沒有顯示。

為何不所有的網站都使用HTTPS

既然HTTPS那么安全可靠，那為何不所有的Web網站都使用HTTPS？
首先，很多人還是會覺得HTTPS實施有門檻，這個門檻在于需要權威CA頒發的SSL證書。從證書的選擇、購買到部署，傳統的模式下都會比較耗時耗力。
其次，HTTPS普遍認為性能消耗要大于HTTP，因為與純文本通信相比，加密通信會消耗更多的CPU及內存資源。如果每次通信都加密，會消耗相當多的資源，平攤到一臺計算機上時，能夠處理的請求數量必定也會隨之減少。但事實并非如此，用戶可以通過性能優化、把證書部署在SLB或CDN，來解決此問題。
除此之外，想要節約購買證書的開銷也是原因之一。要進行HTTPS通信，證書是必不可少的。而使用的證書必須向認證機構（CA）購買。
最后是安全意識。相比國內，國外互聯網行業的安全意識和技術應用相對成熟，HTTPS部署趨勢是由社會、企業、政府共同去推動的。

TCP/IP 網絡模型

計算機與網絡設備要相互通信，雙方就必須基于相同的方法。比如，如何探測到通信目標、由哪一邊先發起通信、使用哪種語言進行通信、怎樣結束通信等規則都需要事先確定。不同的硬件、操作系統之間的通信，所有的這一切都需要一種規則。而我們就把這種規則稱為協議（protocol）。
TCP/IP 是互聯網相關的各類協議族的總稱，比如：TCP，UDP，IP，FTP，HTTP，ICMP，SMTP 等都屬于 TCP/IP 族內的協議。
TCP/IP 模型是互聯網的基礎，它是一系列網絡協議的總稱。這些協議可以劃分為四層，分別為鏈路層、網絡層、傳輸層和應用層。
鏈路層：負責封裝和解封裝 IP 報文，發送和接受 ARP/RARP 報文等。
網絡層：負責路由以及把分組報文發送給目標網絡或主機。
傳輸層：負責對報文進行分組和重組，并以 TCP 或 UDP 協議格式封裝報文。
應用層：負責向用戶提供應用程序，比如 HTTP、FTP、Telnet、DNS、SMTP 等。

在網絡體系結構中網絡通信的建立必須是在通信雙方的對等層進行，不能交錯。 在整個數據傳輸過程中，數據在發送端時經過各層時都要附加上相應層的協議頭和協議尾（僅數據鏈路層需要封裝協議尾）部分，也就是要對數據進行協議封裝，以標識對應層所用的通信協議。

UDP

UDP 協議全稱是用戶數據報協議，在網絡中它與 TCP 協議一樣用于處理數據包，是一種無連接的協議。在 OSI 模型中，在第四層——傳輸層，處于 IP 協議的上一層。UDP 有不提供數據包分組、組裝和不能對數據包進行排序的缺點，也就是說，當報文發送之后，是無法得知其是否安全完整到達的。
它有以下幾個特點：

1.面向無連接

首先 UDP 是不需要和 TCP 一樣在發送數據前進行三次握手建立連接的，想發數據就可以開始發送了。并且也只是數據報文的搬運工，不會對數據報文進行任何拆分和拼接操作。
具體來說就是：
在發送端，應用層將數據傳遞給傳輸層的 UDP 協議，UDP 只會給數據增加一個 UDP 頭標識下是 UDP 協議，然后就傳遞給網絡層了
在接收端，網絡層將數據傳遞給傳輸層，UDP 只去除 IP 報文頭就傳遞給應用層，不會任何拼接操作

2.有單播，多播，廣播的功能

UDP 不止支持一對一的傳輸方式，同樣支持一對多，多對多，多對一的方式，也就是說 UDP 提供了單播，多播，廣播的功能。

3.UDP 是面向報文的

發送方的 UDP 對應用程序交下來的報文，在添加首部后就向下交付 IP 層。UDP 對應用層交下來的報文，既不合并，也不拆分，而是保留這些報文的邊界。因此，應用程序必須選擇合適大小的報文

4.不可靠性

首先不可靠性體現在無連接上，通信都不需要建立連接，想發就發，這樣的情況肯定不可靠。
并且收到什么數據就傳遞什么數據，并且也不會備份數據，發送數據也不會關心對方是否已經正確接收到數據了。

再者網絡環境時好時壞，但是 UDP 因為沒有擁塞控制，一直會以恒定的速度發送數據。即使網絡條件不好，也不會對發送速率進行調整。這樣實現的弊端就是在網絡條件不好的情況下可能會導致丟包，但是優點也很明顯，在某些實時性要求高的場景（比如電話會議）就需要使用 UDP 而不是 TCP。

5.頭部開銷小，傳輸數據報文時是很高效的。

UDP 頭部包含了以下幾個數據：

• 兩個十六位的端口號，分別為源端口（可選字段）和目標端口
• 整個數據報文的長度
• 整個數據報文的檢驗和（IPv4 可選 字段），該字段用于發現頭部信息和數據中的錯誤

因此 UDP 的頭部開銷小，只有八字節，相比 TCP 的至少二十字節要少得多，在傳輸數據報文時是很高效的。

TCP

當一臺計算機想要與另一臺計算機通訊時，兩臺計算機之間的通信需要暢通且可靠，這樣才能保證正確收發數據。例如，當你想查看網頁或查看電子郵件時，希望完整且按順序查看網頁，而不丟失任何內容。當你下載文件時，希望獲得的是完整的文件，而不僅僅是文件的一部分，因為如果數據丟失或亂序，都不是你希望得到的結果，于是就用到了 TCP。

TCP 協議全稱是傳輸控制協議是一種面向連接的、可靠的、基于字節流的傳輸層通信協議，由 IETF 的 RFC 793 定義。TCP 是面向連接的、可靠的流協議。流就是指不間斷的數據結構，你可以把它想象成排水管中的水流。

1.TCP 連接過程

• 第一次握手
  客戶端向服務端發送連接請求報文段。該報文段中包含自身的數據通訊初始序號。請求發送后，客戶端便進入 SYN-SENT 狀態。
• 第二次握手
  服務端收到連接請求報文段后，如果同意連接，則會發送一個應答，該應答中也會包含自身的數據通訊初始序號，發送完成后便進入 SYN-RECEIVED 狀態。
• 第三次握手
  當客戶端收到連接同意的應答后，還要向服務端發送一個確認報文。客戶端發完這個報文段后便進入 ESTABLISHED 狀態，服務端收到這個應答后也進入 ESTABLISHED 狀態，此時連接建立成功。

這里可能大家會有個疑惑：為什么 TCP 建立連接需要三次握手，而不是兩次？這是因為這是為了防止出現失效的連接請求報文段被服務端接收的情況，從而產生錯誤。

2.TCP 斷開鏈接

TCP 是全雙工的，在斷開連接時兩端都需要發送 FIN 和 ACK。

• 第一次握手
  若客戶端 A 認為數據發送完成，則它需要向服務端 B 發送連接釋放請求。
• 第二次握手
  B 收到連接釋放請求后，會告訴應用層要釋放 TCP 鏈接。然后會發送 ACK 包，并進入 CLOSE_WAIT 狀態，此時表明 A 到 B 的連接已經釋放，不再接收 A 發的數據了。但是因為 TCP 連接是雙向的，所以 B 仍舊可以發送數據給 A。
• 第三次握手
  B 如果此時還有沒發完的數據會繼續發送，完畢后會向 A 發送連接釋放請求，然后 B 便進入 LAST-ACK 狀態。
• 第四次握手
  A 收到釋放請求后，向 B 發送確認應答，此時 A 進入 TIME-WAIT 狀態。該狀態會持續 2MSL（最大段生存期，指報文段在網絡中生存的時間，超時會被拋棄） 時間，若該時間段內沒有 B 的重發請求的話，就進入 CLOSED 狀態。當 B 收到確認應答后，也便進入 CLOSED 狀態。

TCP 協議的特點

• 面向連接
  面向連接，是指發送數據之前必須在兩端建立連接。建立連接的方法是“三次握手”，這樣能建立可靠的連接。建立連接，是為數據的可靠傳輸打下了基礎。
• 僅支持單播傳輸
  每條 TCP 傳輸連接只能有兩個端點，只能進行點對點的數據傳輸，不支持多播和廣播傳輸方式。
• 面向字節流
  TCP 不像 UDP 一樣那樣一個個報文獨立地傳輸，而是在不保留報文邊界的情況下以字節流方式進行傳輸。
• 可靠傳輸
  對于可靠傳輸，判斷丟包，誤碼靠的是 TCP 的段編號以及確認號。TCP 為了保證報文傳輸的可靠，就給每個包一個序號，同時序號也保證了傳送到接收端實體的包的按序接收。然后接收端實體對已成功收到的字節發回一個相應的確認(ACK)；如果發送端實體在合理的往返時延(RTT)內未收到確認，那么對應的數據（假設丟失了）將會被重傳。
• 提供擁塞控制
  當網絡出現擁塞的時候，TCP 能夠減小向網絡注入數據的速率和數量，緩解擁塞
• TCP 提供全雙工通信
  TCP 允許通信雙方的應用程序在任何時候都能發送數據，因為 TCP 連接的兩端都設有緩存，用來臨時存放雙向通信的數據。當然，TCP 可以立即發送一個數據段，也可以緩存一段時間以便一次發送更多的數據段（最大的數據段大小取決于 MSS）

TCP 和 UDP 的比較

總結：

• TCP 向上層提供面向連接的可靠服務 ，UDP 向上層提供無連接不可靠服務。
• 雖然 UDP 并沒有 TCP 傳輸來的準確，但是也能在很多實時性要求高的地方有所作為
• 對數據準確性要求高，速度可以相對較慢的，可以選用 TCP