TCP/IP（Transmission Control Protocol/Internet Protocol，傳輸控制協(xié)議/網(wǎng)際協(xié)議）是指能夠在多個(gè)不同網(wǎng)絡(luò)間實(shí)現(xiàn)信息傳輸?shù)膮f(xié)議簇。TCP/IP協(xié)議不僅僅指的是TCP 和IP兩個(gè)協(xié)議，而是指一個(gè)由FTP、SMTP、TCP、UDP、IP等協(xié)議構(gòu)成的協(xié)議簇，同時(shí)是Internet最基本的協(xié)議、Internet國際互聯(lián)網(wǎng)絡(luò)的基礎(chǔ)，由網(wǎng)絡(luò)層的IP協(xié)議和傳輸層的TCP協(xié)議組成。TCP/IP 定義了電子設(shè)備如何連入因特網(wǎng)，以及數(shù)據(jù)如何在它們之間傳輸?shù)臉?biāo)準(zhǔn)。
我的理解： 互聯(lián)網(wǎng)中的設(shè)備要相互通信，必須基于相同的方式，比如由哪一方發(fā)起通訊，使用什么語言進(jìn)行通訊，怎么結(jié)束通訊這些都要事先確定，不同設(shè)備之間的通訊都需要一種規(guī)則，我們將這種規(guī)則成為協(xié)議。
TCP/IP協(xié)議中最重要的特點(diǎn)就是分層。由上往下分別為 應(yīng)用層，傳輸層，網(wǎng)絡(luò)層，數(shù)據(jù)鏈路層，物理層。當(dāng)然也有按不同的模型分為4層或者7層的。
為什么要分層呢？在設(shè)計(jì)的角度來講變得靈活了，當(dāng)某一層需要修改時(shí)，只需要拿掉對(duì)相應(yīng)的層，實(shí)現(xiàn)可拔插，無需變動(dòng)所有層。對(duì)于使用者來講，屏蔽了底層復(fù)雜的傳輸過程。
TCP/IP模型將OSI參考模型中的會(huì)話層和表示層的功能合并到應(yīng)用層實(shí)現(xiàn)。這一層主要的代表有DNS域名解析/http協(xié)議
在TCP/IP模型中，傳輸層的功能是使源端主機(jī)和目標(biāo)端主機(jī)上的對(duì)等實(shí)體可以進(jìn)行會(huì)話。在傳輸層定義了兩種服務(wù)質(zhì)量不同的協(xié)議。即：傳輸控制協(xié)議TCP和用戶數(shù)據(jù)報(bào)協(xié)議UDP.
網(wǎng)絡(luò)層是整個(gè)TCP/IP協(xié)議棧的核心。它的功能是把分組發(fā)往目標(biāo)網(wǎng)絡(luò)或主機(jī)。同時(shí)，為了盡快地發(fā)送分組，可能需要沿不同的路徑同時(shí)進(jìn)行分組傳遞。因此，分組到達(dá)的順序和發(fā)送的順序可能不同，這就需要上層必須對(duì)分組進(jìn)行排序。網(wǎng)絡(luò)層定義了分組格式和協(xié)議，即IP協(xié)議（Internet Protocol ）。
該層負(fù)責(zé) 比特流在節(jié)點(diǎn)之間的傳輸，即負(fù)責(zé)物理傳輸，這一層的協(xié)議既與鏈路有關(guān)，也與傳輸?shù)慕橘|(zhì)有關(guān)。通俗來說就是把計(jì)算機(jī)連接起來的物理手段。
控制網(wǎng)絡(luò)層與物理層之間的通信，主要功能是保證物理線路上進(jìn)行可靠的數(shù)據(jù)傳遞。為了保證傳輸，從網(wǎng)絡(luò)層接收到的數(shù)據(jù)被分割成特定的可被物理層傳輸?shù)膸?。幀是用來移?dòng)數(shù)據(jù)結(jié)構(gòu)的結(jié)構(gòu)包，他不僅包含原始數(shù)據(jù)，還包含發(fā)送方和接收方的物理地址以及糾錯(cuò)和控制信息。其中的地址確定了幀將發(fā)送到何處，而糾錯(cuò)和控制信息則確保幀無差錯(cuò)到達(dá)。如果在傳達(dá)數(shù)據(jù)時(shí)，接收點(diǎn)檢測(cè)到所傳數(shù)據(jù)中有差錯(cuò)，就要通知發(fā)送方重發(fā)這一幀。
用戶數(shù)據(jù)報(bào)協(xié)議 UDP（User Datagram Protocol）:無連接；盡最大努力的交付；面向報(bào)文；無擁塞控制；支持一對(duì)一、一對(duì)多、多對(duì)一、多對(duì)多的交互通信；首部開銷小(只有四個(gè)字段：源端口、目的端口、長(zhǎng)度、檢驗(yàn)和)。UDP是面向報(bào)文的傳輸方式是應(yīng)用層交給UDP多長(zhǎng)的報(bào)文，UDP發(fā)送多長(zhǎng)的報(bào)文，即一次發(fā)送一個(gè)報(bào)文。因此，應(yīng)用程序必須選擇合適大小的報(bào)文。
傳輸控制協(xié)議 TCP（Transmission Control Protocol）:面向連接；每一個(gè)TCP連接只能是點(diǎn)對(duì)點(diǎn)的(一對(duì)一)；提供可靠交付服務(wù)；提供全雙工通信；面向字節(jié)流。應(yīng)用程序和TCP的交互是一次一個(gè)數(shù)據(jù)塊(大小不等)，但TCP把應(yīng)用程序看成是一連串的無結(jié)構(gòu)的字節(jié)流。TCP有一個(gè)緩沖，當(dāng)應(yīng)該程序傳送的數(shù)據(jù)塊太長(zhǎng)，TCP就可以把它劃分短一些再傳送。
UDP的首部格式:
用戶數(shù)據(jù)報(bào)有兩個(gè)字段：數(shù)據(jù)字段和首部字段，數(shù)據(jù)字段很簡(jiǎn)單，只有8個(gè)字節(jié)，由四個(gè)字段組成，每個(gè)字段的長(zhǎng)度都是兩個(gè)字節(jié)。各字段意義如下：
源端口： 源端口號(hào)，在需要給對(duì)方回信時(shí)使用。不需要是可全用0.
目的端口號(hào)： 這在終點(diǎn)交付報(bào)文時(shí)必須使用。
長(zhǎng)度： 用戶數(shù)據(jù)報(bào)UDP的長(zhǎng)度，最小為8（僅首部）。
校驗(yàn)和： 用于校驗(yàn)用戶數(shù)據(jù)報(bào)在傳輸過程是否出錯(cuò)，出錯(cuò)則丟棄該報(bào)文。
源端口和目的端口: 各占兩個(gè)字節(jié)，分別寫入源端口號(hào)和目的端口號(hào)。序號(hào) ： 占4個(gè)字節(jié)；用于對(duì)字節(jié)流進(jìn)行編號(hào)，例如序號(hào)為 301，表示第一個(gè)字節(jié)的編號(hào)為 301，如果攜帶的數(shù)據(jù)長(zhǎng)度為 100 字節(jié)，那么下一個(gè)報(bào)文段的序號(hào)應(yīng)為 401。確認(rèn)號(hào) ： 占4個(gè)字節(jié)；期望收到的下一個(gè)報(bào)文段的序號(hào)。例如 B 正確收到 A 發(fā)送來的一個(gè)報(bào)文段，序號(hào)為 501，攜帶的數(shù)據(jù)長(zhǎng)度為 200 字節(jié)，因此 B 期望下一個(gè)報(bào)文段的序號(hào)為 701，B 發(fā)送給 A 的確認(rèn)報(bào)文段中確認(rèn)號(hào)就為 701。數(shù)據(jù)偏移 ： 占4位；指的是數(shù)據(jù)部分距離報(bào)文段起始處的偏移量，實(shí)際上指的是首部的長(zhǎng)度。確認(rèn) ACK ： 當(dāng) ACK=1 時(shí)確認(rèn)號(hào)字段有效，否則無效。TCP 規(guī)定，在連接建立后所有傳送的報(bào)文段都必須把 ACK 置 1。同步 SYN ：在連接建立時(shí)用來同步序號(hào)。當(dāng) SYN=1，ACK=0 時(shí)表示這是一個(gè)連接請(qǐng)求報(bào)文段。若對(duì)方同意建立連接，則響應(yīng)報(bào)文中 SYN=1，ACK=1。終止 FIN ： 用來釋放一個(gè)連接，當(dāng) FIN=1 時(shí)，表示此報(bào)文段的發(fā)送方的數(shù)據(jù)已發(fā)送完畢，并要求釋放連接。窗口 ： 占2字節(jié)；窗口值作為接收方讓發(fā)送方設(shè)置其發(fā)送窗口的依據(jù)。之所以要有這個(gè)限制，是因?yàn)榻邮辗降臄?shù)據(jù)緩存空間是有限的。檢驗(yàn)和： 占2個(gè)字節(jié)；檢驗(yàn)和字段檢驗(yàn)的范圍包括首部和數(shù)據(jù)這兩個(gè)部分。在計(jì)算檢驗(yàn)和時(shí)，在TCP報(bào)文段的前面加上12字節(jié)的偽首部。套接字： TCP連接的端點(diǎn)叫做套接字或插口。端口號(hào)拼接到IP地址即構(gòu)成了套接字。
TCP的三次握手與四次揮手：
第一次握手：Client將標(biāo)志位SYN置為1，隨機(jī)產(chǎn)生一個(gè)值seq=J，并將該數(shù)據(jù)包發(fā)送給Server，Client進(jìn)入SYN_SENT狀態(tài)，等待Server確認(rèn)。
第二次握手：Server收到數(shù)據(jù)包后由標(biāo)志位SYN=1知道Client請(qǐng)求建立連接，Server將標(biāo)志位SYN和ACK都置為1，ack=J+1，隨機(jī)產(chǎn)生一個(gè)值seq=K，并將該數(shù)據(jù)包發(fā)送給Client以確認(rèn)連接請(qǐng)求，Server進(jìn)入SYN_RCVD狀態(tài)。
第三次握手：Client收到確認(rèn)后，檢查ack是否為J+1，ACK是否為1，如果正確則將標(biāo)志位ACK置為1，ack=K+1，并將該數(shù)據(jù)包發(fā)送給Server，Server檢查ack是否為K+1，ACK是否為1，如果正確則連接建立成功，Client和Server進(jìn)入ESTABLISHED狀態(tài)，完成三次握手，隨后Client與Server之間可以開始傳輸數(shù)據(jù)了。
為什么要進(jìn)行三次握手呢? 第三次握手是為了防止失效的連接請(qǐng)求到達(dá)服器，讓服務(wù)器錯(cuò)誤打開連接?？蛻舳税l(fā)送的連接請(qǐng)求如果在網(wǎng)絡(luò)中滯留，那么就會(huì)隔很長(zhǎng)一段時(shí)間才能收到服務(wù)器端發(fā)回的連接確認(rèn)。客戶端等待一個(gè)超時(shí)重傳時(shí)間之后，就會(huì)重新請(qǐng)求連接。但是這個(gè)滯留的連接請(qǐng)求最后還是會(huì)到達(dá)服務(wù)器，如果不進(jìn)行三次握手，那么服務(wù)器就會(huì)打開兩個(gè)連接。如果有第三次握手，客戶端會(huì)忽略服務(wù)器之后發(fā)送的對(duì)滯留連接請(qǐng)求的連接確認(rèn)，不進(jìn)行第三次握手，因此就不會(huì)再次打開連接。
如果此時(shí)變成兩次揮手行不行？舉個(gè)打電話的例子，比如：第一次握手：A給B打電話說，你可以聽到我說話嗎？第二次握手：B收到了A的信息，然后對(duì)A說：我可以聽得到你說話啊，你能聽得到我說話嗎？第三次握手：A收到了B的信息，然后說可以的，我要給你發(fā)信息啦！結(jié)論：在三次握手之后，A和B都能確定這么一件事：我能聽到你，你也能聽到我。這樣，就可以開始正常通信了。如果是兩次，那將無法確定。
當(dāng)數(shù)據(jù)傳送完畢,斷開連接就需要進(jìn)行TCP的四次揮手：
第一次揮手，客戶端設(shè)置seq和 ACK ,向服務(wù)器發(fā)送一個(gè) FIN(終結(jié))報(bào)文段。此時(shí)，客戶端進(jìn)入 FIN_WAIT_1狀態(tài)，表示客戶端沒有數(shù)據(jù)要發(fā)送給服務(wù)端了。
第二次揮手，服務(wù)端收到了客戶端發(fā)送的 FIN 報(bào)文段，向客戶端回了一個(gè) ACK 報(bào)文段。
第三次揮手，服務(wù)端向客戶端發(fā)送FIN 報(bào)文段，請(qǐng)求關(guān)閉連接，同時(shí)服務(wù)端進(jìn)入 LAST_ACK 狀態(tài)。
第四次揮手，客戶端收到服務(wù)端發(fā)送的 FIN 報(bào)文段后，向服務(wù)端發(fā)送 ACK 報(bào)文段,然后客戶端進(jìn)入 TIME_WAIT狀態(tài)。服務(wù)端收到客戶端的 ACK 報(bào)文段以后，就關(guān)閉連接。此時(shí)，客戶端等待2MSL（指一個(gè)片段在網(wǎng)絡(luò)中最大的存活時(shí)間）后依然沒有收到回復(fù)，則說明服務(wù)端已經(jīng)正常關(guān)閉，這樣客戶端就可以關(guān)閉連接了。四次揮手
最后完整的過程圖
為什么要四次揮手？
客戶端發(fā)送了 FIN 連接釋放報(bào)文之后，服務(wù)器收到了這個(gè)報(bào)文，就進(jìn)入了 CLOSE-WAIT 狀態(tài)。這個(gè)狀態(tài)是為了讓服務(wù)器端發(fā)送還未傳送完畢的數(shù)據(jù)，傳送完畢之后，服務(wù)器會(huì)發(fā)送 FIN 連接釋放報(bào)文。
HTTP持久連接
如果有大量的連接，每次在連接，關(guān)閉都要經(jīng)歷三次握手，四次揮手，這顯然會(huì)造成性能低下。因此。Http 有一種叫做 長(zhǎng)連接（keepalive connections） 的機(jī)制。它可以在傳輸數(shù)據(jù)后仍保持連接，當(dāng)客戶端需要再次獲取數(shù)據(jù)時(shí)，直接使用剛剛空閑下來的連接而無需再次握手。
什么是HTTP?
超文本傳輸協(xié)議，是一個(gè)基于請(qǐng)求與響應(yīng)，無狀態(tài)的，應(yīng)用層的協(xié)議，?；赥CP/IP協(xié)議傳輸數(shù)據(jù)，互聯(lián)網(wǎng)上應(yīng)用最為廣泛的一種網(wǎng)絡(luò)協(xié)議,所有的WWW文件都必須遵守這個(gè)標(biāo)準(zhǔn)。設(shè)計(jì)HTTP的初衷是為了提供一種發(fā)布和接收HTML頁面的方法。
HTTP特點(diǎn)：
無狀態(tài)：協(xié)議對(duì)客戶端沒有狀態(tài)存儲(chǔ)，對(duì)事物處理沒有“記憶”能力，比如訪問一個(gè)網(wǎng)站需要反復(fù)進(jìn)行登錄操作。
無連接：HTTP/1.1之前，由于無狀態(tài)特點(diǎn)，每次請(qǐng)求需要通過TCP三次握手四次揮手，和服務(wù)器重新建立連接。比如某個(gè)客戶機(jī)在短時(shí)間多次請(qǐng)求同一個(gè)資源，服務(wù)器并不能區(qū)別是否已經(jīng)響應(yīng)過用戶的請(qǐng)求，所以每次需要重新響應(yīng)請(qǐng)求，需要耗費(fèi)不必要的時(shí)間和流量。
基于請(qǐng)求和響應(yīng)：基本的特性，由客戶端發(fā)起請(qǐng)求，服務(wù)端響應(yīng)。
簡(jiǎn)單快速、靈活。
通信使用明文、請(qǐng)求和響應(yīng)不會(huì)對(duì)通信方進(jìn)行確認(rèn)、無法保護(hù)數(shù)據(jù)的完整性。
HTTP報(bào)文組成:
請(qǐng)求行：包括請(qǐng)求方法、URL、協(xié)議/版本
請(qǐng)求頭(Request Header)
請(qǐng)求正文
狀態(tài)行
響應(yīng)頭
響應(yīng)正文
HTTP的缺點(diǎn)：
通信使用明文（不加密），內(nèi)容可能會(huì)被竊聽。
不驗(yàn)證通信方的身份，因此有可能遭遇偽裝。
無法證明報(bào)文的完整性，所以有可能已遭篡改。
HTTPS：是以安全為目標(biāo)的HTTP通道，簡(jiǎn)單講是HTTP的安全版，即HTTP下加入SSL層，HTTPS的安全基礎(chǔ)是SSL，因此加密的詳細(xì)內(nèi)容就需要SSL。HTTPS協(xié)議的主要作用可以分為兩種：一種是建立一個(gè)信息安全通道，來保證數(shù)據(jù)傳輸?shù)陌踩涣硪环N就是確認(rèn)網(wǎng)站的真實(shí)性。
HTTPS 并非是應(yīng)用層的一種新協(xié)議。只是 HTTP 通信接口部分用SSL（Secure Socket Layer）和 TLS（Transport Layer Security）協(xié)議代替而已。通常，HTTP 直接和 TCP 通信。當(dāng)使用 SSL時(shí)，則演變成先和 SSL通信，再由 SSL和 TCP 通信了。簡(jiǎn)言之，所謂 HTTPS，其實(shí)就是身披SSL協(xié)議這層外殼的 HTTP。
HTTPS通訊方式：
客戶使用https的URL訪問Web服務(wù)器，要求與Web服務(wù)器建立SSL連接。
Web服務(wù)器收到客戶端請(qǐng)求后，會(huì)將網(wǎng)站的證書信息（證書中包含公鑰）傳送一份給客戶端。
客戶端的瀏覽器與Web服務(wù)器開始協(xié)商SSL連接的安全等級(jí)，也就是信息加密的等級(jí)。
客戶端的瀏覽器根據(jù)雙方同意的安全等級(jí)，建立會(huì)話密鑰，然后利用網(wǎng)站的公鑰將會(huì)話密鑰加密，并傳送給網(wǎng)站。
Web服務(wù)器利用自己的私鑰解密出會(huì)話密鑰。
Web服務(wù)器利用會(huì)話密鑰加密與客戶端之間的通信。
SSL不僅提供加密處理，加密方式為混合加密。
SSL而且還使用了一種被稱為證書的手段，可用于確定方。證書由值得信任的第三方機(jī)構(gòu)頒發(fā)，用以證明服務(wù)器和客戶端是實(shí)際存在的。另外，偽造證書從技術(shù)角度來說是異常困難的一件事。所以只要能夠確認(rèn)通信方（服務(wù)器或客戶端）持有的證書。
加密方法
對(duì)稱加密：加密和解密同用一個(gè)密鑰的方式稱為共享密鑰加密（Common keycrypto system），也被叫做對(duì)稱密鑰加密.
對(duì)成加密的方式效率比較低，加密速度慢。另外對(duì)稱加密存在安全隱患的問題，堆成加密的密鑰必須要傳到對(duì)方對(duì)方才能解密，要是對(duì)方在密鑰傳輸?shù)倪^程獲取到密鑰，那不是密鑰失去了加密的意義，所以完全使用對(duì)稱加密也是不安全的。
非對(duì)稱加密：公開密鑰加密使用一對(duì)非對(duì)稱的密鑰。一把叫做私有密鑰（private key），另一把叫做公開密鑰（public key）。顧名思義，私有密鑰不能讓其他任何人知道，而公開密鑰則可以隨意發(fā)布，任何人都可以獲得。公鑰加密，私鑰解密使用公開密鑰加密方式，發(fā)送密文的一方使用對(duì)方的公開密鑰進(jìn)行加密處理，對(duì)方收到被加密的信息后，再使用自己的私有密鑰進(jìn)行解密。
那么非對(duì)稱個(gè)加密就一定安全嗎？非對(duì)稱加密也不安全，為什么呢？因?yàn)榇嬖谥虚g偽造公鑰和私鑰，假如在公鑰傳給對(duì)方的時(shí)候，有人獲取到公鑰，雖然她不能用你的公鑰做什么，但是它截獲公鑰后，把自己偽造的公鑰發(fā)送給對(duì)方，這樣對(duì)方獲取的就不是真正的公鑰，當(dāng)對(duì)方用公鑰進(jìn)行加密文件，再將文件發(fā)送給對(duì)方，這樣即使截獲人沒有獲取到真正的私鑰，但是加密時(shí)的公鑰是截獲人的，他獲取到加密文件，只需要用自己的私鑰進(jìn)行解密就成功獲取到文件了。
混合加密機(jī)制（對(duì)稱加密與非對(duì)稱加密結(jié)合的方式）顧名思義也就是對(duì)稱加密和非對(duì)稱加密的方式相結(jié)合。
如何證明公開沒要本身的真實(shí)性。因?yàn)樵诠_秘鑰傳輸?shù)倪^程中，可能真正的公開秘鑰已經(jīng)被攻擊者替換掉了。
為了解決上述問題，于是除了CA認(rèn)證證書。服務(wù)器將CA證書發(fā)送給客戶端，以進(jìn)行公開密鑰加密方式通信。接到證書的客戶端可使用數(shù)字證書認(rèn)證機(jī)構(gòu)的公開密鑰，對(duì)那張證書上的數(shù)字簽名進(jìn)行驗(yàn)證，一旦驗(yàn)證通過，客戶端便可明確兩件事：
一：認(rèn)證服務(wù)器的公開密鑰的是真實(shí)有效的數(shù)字證書認(rèn)證機(jī)構(gòu)；
二：服務(wù)器的公開密鑰是值得信賴的。
那么公開密鑰如何交接給客戶端是一件非常重要的事，因此多數(shù)瀏覽器開發(fā)商發(fā)布版本時(shí)，會(huì)事先在內(nèi)部植入常用認(rèn)證機(jī)關(guān)的公開密鑰，這樣就確保公鑰是使用認(rèn)證機(jī)構(gòu)的公鑰避免了公鑰偽造的過程，進(jìn)而確保了安全。
作者：非科班的科班
來源：微信公眾號(hào)
聯(lián)系客服
