TCP/IP概念
TCP/IP（Transmission Control Protocol/Internet Protocol，傳輸控制協議/網際協議）是指可以在多個不一樣網絡間實現信息傳輸的協議簇。TCP/IP協議不只僅指的是TCP 和IP兩個協議，而是指一個由FTP、SMTP、TCP、UDP、IP等協議構成的協議簇，同時是Internet最基本的協議、Internet國際互聯網絡的基礎，由網絡層的IP協議和傳輸層的TCP協議組成。TCP/IP 定義了電子設備如何連入因特網，以及數據如何在它們之間傳輸的標準。面試
個人理解： 互聯網中的設備要相互通訊，必須基於相同的方式，好比由哪一方發起通信，使用什麼語言進行通信，怎麼結束通信這些都要事先肯定，不一樣設備之間的通信都須要一種規則，咱們將這種規則成爲協議。瀏覽器
TCP/IP 的分層管理圖
TCP/IP協議中最重要的特色就是分層。由上往下分別爲 應用層，傳輸層，網絡層，數據鏈路層，物理層。固然也有按不一樣的模型分爲4層或者7層的。
爲何要分層呢？在設計的角度來說變得靈活了，當某一層須要修改時，只須要拿掉對相應的層，實現可拔插，無需變更全部層。對於使用者來說，屏蔽了底層複雜的傳輸過程。緩存
應用層
TCP/IP模型將OSI參考模型中的會話層和表示層的功能合併到應用層實現。這一層主要的表明有DNS域名解析/http協議安全
傳輸層
在TCP/IP模型中，傳輸層的功能是使源端主機和目標端主機上的對等實體能夠進行會話。在傳輸層定義了兩種服務質量不一樣的協議。即：傳輸控制協議TCP和用戶數據報協議UDP.服務器
網絡層
網絡層是整個TCP/IP協議棧的核心。它的功能是把分組發往目標網絡或主機。同時，爲了儘快地發送分組，可能須要沿不一樣的路徑同時進行分組傳遞。所以，分組到達的順序和發送的順序可能不一樣，這就須要上層必須對分組進行排序。網絡層定義了分組格式和協議，即IP協議（Internet Protocol ）。微信
物理層
該層負責 比特流在節點之間的傳輸，即負責物理傳輸，這一層的協議既與鏈路有關，也與傳輸的介質有關。通俗來講就是把計算機鏈接起來的物理手段。網絡
數據鏈路層
控制網絡層與物理層之間的通訊，主要功能是保證物理線路上進行可靠的數據傳遞。爲了保證傳輸，從網絡層接收到的數據被分割成特定的可被物理層傳輸的幀。幀是用來移動數據結構的結構包，他不只包含原始數據，還包含發送方和接收方的物理地址以及糾錯和控制信息。其中的地址肯定了幀將發送到何處，而糾錯和控制信息則確保幀無差錯到達。若是在傳達數據時，接收點檢測到所傳數據中有差錯，就要通知發送方重發這一幀。數據結構
UDP 和 TCP 的特色:
用戶數據報協議 UDP（User Datagram Protocol）:無鏈接；盡最大努力的交付；面向報文；無擁塞控制；支持一對1、一對多、多對1、多對多的交互通訊；首部開銷小(只有四個字段：源端口、目的端口、長度、檢驗和)。UDP是面向報文的傳輸方式是應用層交給UDP多長的報文，UDP發送多長的報文，即一次發送一個報文。所以，應用程序必須選擇合適大小的報文。性能
傳輸控制協議 TCP（Transmission Control Protocol）:面向鏈接；每個TCP鏈接只能是點對點的(一對一)；提供可靠交付服務；提供全雙工通訊；面向字節流。應用程序和TCP的交互是一次一個數據塊(大小不等)，但TCP把應用程序當作是一連串的無結構的字節流。TCP有一個緩衝，當應該程序傳送的數據塊太長，TCP就能夠把它劃分短一些再傳送。網站
UDP的首部格式:
用戶數據報有兩個字段：數據字段和首部字段，數據字段很簡單，只有8個字節，由四個字段組成，每一個字段的長度都是兩個字節。各字段意義以下：
源端口： 源端口號，在須要給對方回信時使用。不須要是可全用0.
目的端口號： 這在終點交付報文時必須使用。
長度： 用戶數據報UDP的長度，最小爲8（僅首部）。
校驗和： 用於校驗用戶數據報在傳輸過程是否出錯，出錯則丟棄該報文。
TCP報文首部格式:
源端口和目的端口: 各佔兩個字節，分別寫入源端口號和目的端口號。
序號 ： 佔4個字節；用於對字節流進行編號，例如序號爲 301，表示第一個字節的編號爲 301，若是攜帶的數據長度爲 100 字節，那麼下一個報文段的序號應爲 401。
確認號 ： 佔4個字節；指望收到的下一個報文段的序號。例如 B 正確收到 A 發送來的一個報文段，序號爲 501，攜帶的數據長度爲 200 字節，所以 B 指望下一個報文段的序號爲 701，B 發送給 A 的確認報文段中確認號就爲 701。
數據偏移 ： 佔4位；指的是數據部分距離報文段起始處的偏移量，實際上指的是首部的長度。
確認 ACK ： 當 ACK=1 時確認號字段有效，不然無效。TCP 規定，在鏈接創建後全部傳送的報文段都必須把 ACK 置 1。
同步 SYN ：在鏈接創建時用來同步序號。當 SYN=1，ACK=0 時表示這是一個鏈接請求報文段。若對方贊成創建鏈接，則響應報文中 SYN=1，ACK=1。
終止 FIN ： 用來釋放一個鏈接，當 FIN=1 時，表示此報文段的發送方的數據已發送完畢，並要求釋放鏈接。
窗口 ： 佔2字節；窗口值做爲接收方讓發送方設置其發送窗口的依據。之因此要有這個限制，是由於接收方的數據緩存空間是有限的。
檢驗和： 佔2個字節；檢驗和字段檢驗的範圍包括首部和數據這兩個部分。在計算檢驗和時，在TCP報文段的前面加上12字節的僞首部。
套接字： TCP鏈接的端點叫作套接字或插口。端口號拼接到IP地址即構成了套接字。
面試靈魂拷問
TCP的三次握手與四次揮手
第一次握手：Client將標誌位SYN置爲1，隨機產生一個值seq=J，並將該數據包發送給Server，Client進入SYN_SENT狀態，等待Server確認。
第二次握手：Server收到數據包後由標誌位SYN=1知道Client請求創建鏈接，Server將標誌位SYN和ACK都置爲1，ack=J+1，隨機產生一個值seq=K，並將該數據包發送給Client以確認鏈接請求，Server進入SYN_RCVD狀態。
第三次握手：Client收到確認後，檢查ack是否爲J+1，ACK是否爲1，若是正確則將標誌位ACK置爲1，ack=K+1，並將該數據包發送給Server，Server檢查ack是否爲K+1，ACK是否爲1，若是正確則鏈接創建成功，Client和Server進入ESTABLISHED狀態，完成三次握手，隨後Client與Server之間能夠開始傳輸數據了。
爲何要進行三次握手呢?
第三次握手是爲了防止失效的鏈接請求到達服器，讓服務器錯誤打開鏈接。客戶端發送的鏈接請求若是在網絡中滯留，那麼就會隔很長一段時間才能收到服務器端發回的鏈接確認。客戶端等待一個超時重傳時間以後，就會從新請求鏈接。可是這個滯留的鏈接請求最後仍是會到達服務器，若是不進行三次握手，那麼服務器就會打開兩個鏈接。若是有第三次握手，客戶端會忽略服務器以後發送的對滯留鏈接請求的鏈接確認，不進行第三次握手，所以就不會再次打開鏈接。若是此時變成兩次揮手行不行？
舉個打電話的例子，好比：
第一次握手：A給B打電話說，你能夠聽到我說話嗎？
第二次握手：B收到了A的信息，而後對A說：我能夠聽獲得你說話啊，你能聽獲得我說話嗎？
第三次握手：A收到了B的信息，而後說能夠的，我要給你發信息啦！
結論：
在三次握手以後，A和B都能肯定這麼一件事：我能聽到你，你也能聽到我。這樣，就能夠開始正常通訊了。若是是兩次，那將沒法肯定。
當數據傳送完畢,斷開鏈接就須要進行TCP的四次揮手：
第一次揮手，客戶端設置seq和 ACK ,向服務器發送一個 FIN(終結)報文段。此時，客戶端進入 FIN_WAIT_1
狀態，表示客戶端沒有數據要發送給服務端了。第二次揮手，服務端收到了客戶端發送的 FIN 報文段，向客戶端回了一個 ACK 報文段。
第三次揮手，服務端向客戶端發送FIN 報文段，請求關閉鏈接，同時服務端進入 LAST_ACK 狀態。
第四次揮手，客戶端收到服務端發送的 FIN 報文段後，向服務端發送 ACK 報文段,而後客戶端進入 TIME_WAIT狀態。服務端收到客戶端的 ACK 報文段之後，就關閉鏈接。此時，客戶端等待2MSL（指一個片斷在網絡中最大的存活時間）後依然沒有收到回覆，則說明服務端已經正常關閉，這樣客戶端就能夠關閉鏈接了。
四次揮手
最後完整的過程圖
爲何要四次揮手？
客戶端發送了 FIN 鏈接釋放報文以後，服務器收到了這個報文，就進入了 CLOSE-WAIT 狀態。這個狀態是爲了讓服務器端發送還未傳送完畢的數據，傳送完畢以後，服務器會發送 FIN 鏈接釋放報文。
HTTP持久鏈接
若是有大量的鏈接，每次在鏈接，關閉都要經歷三次握手，四次揮手，這顯然會形成性能低下。所以。Http 有一種叫作 長鏈接（keepalive connections） 的機制。它能夠在傳輸數據後仍保持鏈接，當客戶端須要再次獲取數據時，直接使用剛剛空閒下來的鏈接而無需再次握手。
HTTP和HTTPS
什麼是HTTP?
超文本傳輸協議，是一個基於請求與響應，無狀態的，應用層的協議，常基於TCP/IP協議傳輸數據，互聯網上應用最爲普遍的一種網絡協議,全部的WWW文件都必須遵照這個標準。設計HTTP的初衷是爲了提供一種發佈和接收HTML頁面的方法。
HTTP特色：
無狀態：協議對客戶端沒有狀態存儲，對事物處理沒有「記憶」能力，好比訪問一個網站須要反覆進行登陸操做。
無鏈接：HTTP/1.1以前，因爲無狀態特色，每次請求須要經過TCP三次握手四次揮手，和服務器從新創建鏈接。好比某個客戶機在短期屢次請求同一個資源，服務器並不能區別是否已經響應過用戶的請求，因此每次須要從新響應請求，須要耗費沒必要要的時間和流量。
基於請求和響應：基本的特性，由客戶端發起請求，服務端響應。
簡單快速、靈活。
通訊使用明文、請求和響應不會對通訊方進行確認、沒法保護數據的完整性。
HTTP報文組成:
請求行：包括請求方法、URL、協議/版本
請求頭(Request Header)
請求正文
狀態行
響應頭
響應正文
通訊使用明文（不加密），內容可能會被竊聽。
不驗證通訊方的身份，所以有可能遭遇假裝。
沒法證實報文的完整性，因此有可能已遭篡改。
什麼是HTTPS?
HTTPS：是以安全爲目標的HTTP通道，簡單講是HTTP的安全版，即HTTP下加入SSL層，HTTPS的安全基礎是SSL，所以加密的詳細內容就須要SSL。
HTTPS協議的主要做用能夠分爲兩種：一種是創建一個信息安全通道，來保證數據傳輸的安全；另外一種就是確認網站的真實性。
HTTPS 並不是是應用層的一種新協議。只是 HTTP 通訊接口部分用SSL（Secure Socket Layer）和 TLS（Transport Layer Security）協議代替而已。一般，HTTP 直接和 TCP 通訊。當使用 SSL時，則演變成先和 SSL通訊，再由 SSL和 TCP 通訊了。簡言之，所謂 HTTPS，其實就是身披SSL協議這層外殼的 HTTP。
HTTPS通信方式：
客戶使用https的URL訪問Web服務器，要求與Web服務器創建SSL鏈接。
Web服務器收到客戶端請求後，會將網站的證書信息（證書中包含公鑰）傳送一份給客戶端。
客戶端的瀏覽器與Web服務器開始協商SSL鏈接的安全等級，也就是信息加密的等級。
客戶端的瀏覽器根據雙方贊成的安全等級，創建會話密鑰，而後利用網站的公鑰將會話密鑰加密，並傳送給網站。
Web服務器利用本身的私鑰解密出會話密鑰。
Web服務器利用會話密鑰加密與客戶端之間的通訊。
爲何HTTPS安全
SSL不只提供加密處理，加密方式爲混合加密。
SSL並且還使用了一種被稱爲證書的手段，可用於肯定方。證書由值得信任的第三方機構頒發，用以證實服務器和客戶端是實際存在的。另外，僞造證書從技術角度來講是異常困難的一件事。因此只要可以確認通訊方（服務器或客戶端）持有的證書。
加密方法
對稱加密：
加密和解密同用一個密鑰的方式稱爲共享密鑰加密（Common keycrypto system），也被叫作對稱密鑰加密.
對成加密的方式效率比較低，加密速度慢。另外對稱加密存在安全隱患的問題，堆成加密的密鑰必需要傳到對方對方纔能解密，要是對方在密鑰傳輸的過程獲取到密鑰，那不是密鑰失去了加密的意義，因此徹底使用對稱加密也是不安全的。
非對稱加密：
公開密鑰加密使用一對非對稱的密鑰。一把叫作私有密鑰（private key），另外一把叫作公開密鑰（public key）。顧名思義，私有密鑰不能讓其餘任何人知道，而公開密鑰則能夠隨意發佈，任何人均可以得到。公鑰加密，私鑰解密
使用公開密鑰加密方式，發送密文的一方使用對方的公開密鑰進行加密處理，對方收到被加密的信息後，再使用本身的私有密鑰進行解密。
那麼非對稱個加密就必定安全嗎？非對稱加密也不安全，爲何呢？由於存在中間僞造公鑰和私鑰，假如在公鑰傳給對方的時候，有人獲取到公鑰，雖然她不能用你的公鑰作什麼，可是它截獲公鑰後，把本身僞造的公鑰發送給對方，這樣對方獲取的就不是真正的公鑰，當對方用公鑰進行加密文件，再將文件發送給對方，這樣即便截獲人沒有獲取到真正的私鑰，可是加密時的公鑰是截獲人的，他獲取到加密文件，只須要用本身的私鑰進行解密就成功獲取到文件了。
混合加密機制（對稱加密與非對稱加密結合的方式）
顧名思義也就是對稱加密和非對稱加密的方式相結合。
如何證實公開沒要自己的真實性。由於在公開祕鑰傳輸的過程當中，可能真正的公開祕鑰已經被攻擊者替換掉了。
爲了解決上述問題，因而除了CA認證證書。服務器將CA證書發送給客戶端，以進行公開密鑰加密方式通訊。接到證書的客戶端可以使用數字證書認證機構的公開密鑰，對那張證書上的數字簽名進行驗證，一旦驗證經過，客戶端即可明確兩件事：
一，認證服務器的公開密鑰的是真實有效的數字證書認證機構。
二，服務器的公開密鑰是值得信賴的。
那麼公開密鑰如何交接給客戶端是一件很是重要的事，所以多數瀏覽器開發商發佈版本時，會事先在內部植入經常使用認證機關的公開密鑰，這樣就確保公鑰是使用認證機構的公鑰避免了公鑰僞造的過程，進而確保了安全。
本文分享自微信公衆號 - 非科班的科班（LDCldc123095）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。