本文首發於我的個人部落格：尾尾部落
OSI，TCP/IP，五層協議的體系結構
每一層的作用：
- 物理層：通過媒介傳輸位元,確定機械及電氣規範（位元Bit）
- 資料鏈路層：將位元組裝成幀和點到點的傳遞（幀Frame）
- 網路層：負責資料包從源到宿的傳遞和網際互連（包Packet）
- 傳輸層：提供端到端的可靠報文傳遞和錯誤恢復（段Segment）
- 會話層：建立、管理和終止會話（會話協議資料單元SPDU）
- 表示層：對資料進行翻譯、加密和壓縮（表示協議資料單元PPDU）
- 應用層：允許訪問OSI環境的手段（應用協議資料單元APDU）
每一層的協議：
- 物理層：RJ45、CLOCK、IEEE802.3 （中繼器，集線器，閘道器）
- 資料鏈路：PPP、FR、HDLC、VLAN、MAC （網橋，交換機）
- 網路層：IP、ICMP、ARP、RARP、OSPF、IPX、RIP、IGRP、 （路由器）
- 傳輸層：TCP、UDP、SPX
- 會話層：NFS、SQL、NETBIOS、RPC
- 表示層：JPEG、MPEG、ASII
- 應用層：FTP、DNS、Telnet、SMTP、HTTP、WWW、NFS
TCP對應的應用層協議
- FTP：定義了檔案傳輸協議，使用21埠。常說某某計算機開了FTP服務便是啟動了檔案傳輸服務。下載檔案，上傳主頁，都要用到FTP服務。
- Telnet：它是一種用於遠端登陸的埠，使用者可以以自己的身份遠端連線到計算機上，通過這種埠可以提供一種基於DOS模式下的通訊服務。如以前的BBS是-純字元介面的，支援BBS的伺服器將23埠開啟，對外提供服務。
- SMTP：定義了簡單郵件傳送協議，現在很多郵件伺服器都用的是這個協議，用於傳送郵件。如常見的免費郵件服務中用的就是這個郵件服務埠，所以在電子郵件設定-中常看到有這麼SMTP埠設定這個欄，伺服器開放的是25號埠。
- POP3：它是和SMTP對應，POP3用於接收郵件。通常情況下，POP3協議所用的是110埠。也是說，只要你有相應的使用POP3協議的程式（例如Fo-xmail或Outlook），就可以不以Web方式登陸進郵箱介面，直接用郵件程式就可以收到郵件（如是163郵箱就沒有必要先進入網易網站，再進入自己的郵-箱來收信）。
- HTTP：從Web伺服器傳輸超文字到本地瀏覽器的傳送協議。
UDP對應的應用層協議
- DNS：用於域名解析服務，將域名地址轉換為IP地址。DNS用的是53號埠。
- SNMP：簡單網路管理協議，使用161號埠，是用來管理網路裝置的。由於網路裝置很多，無連線的服務就體現出其優勢。
- TFTP(Trival File Transfer Protocal)：簡單檔案傳輸協議，該協議在熟知埠69上使用UDP服務。
IP地址的分類
- A類地址：以0開頭， 第一個位元組範圍：0~127（1.0.0.0 - 126.255.255.255）；
- B類地址：以10開頭， 第一個位元組範圍：128~191（128.0.0.0 - 191.255.255.255）；
- C類地址：以110開頭， 第一個位元組範圍：192~223（192.0.0.0 - 223.255.255.255）；
10.0.0.0—10.255.255.255， 172.16.0.0—172.31.255.255， 192.168.0.0—192.168.255.255。（Internet上保留地址用於內部）
ARP協議
ARP地址解析協議，簡單說就是，在IP乙太網中，當一個上層協議要發包時，有了該節點的IP地址，ARP就能提供該節點的MAC地址。它的工作原理如下：
- 首先，每個主機都會在自己的ARP緩衝區中建立一個ARP列表，以表示IP地址和MAC地址之間的對應關係。
- 當源主機要傳送資料時，首先檢查ARP列表中是否有對應IP地址的目的主機的MAC地址，如果有，則直接傳送資料，如果沒有，就向本網段的所有主機傳送ARP資料包，該資料包包括的內容有：源主機IP地址，源主機MAC地址，目的主機的IP地址。
- 當本網路的所有主機收到該ARP資料包時，首先檢查資料包中的IP地址是否是自己的IP地址，如果不是，則忽略該資料包，如果是，則首先從資料包中取出源主機的IP和MAC地址寫入到ARP列表中，如果已經存在，則覆蓋，然後將自己的MAC地址寫入ARP響應包中，告訴源主機自己是它想要找的MAC地址。
- 源主機收到ARP響應包後。將目的主機的IP和MAC地址寫入ARP列表，並利用此資訊傳送資料。如果源主機一直沒有收到ARP響應資料包，表示ARP查詢失敗。
- 如果目標IP與自己不在同一個網段，這種情況需要將包發給預設閘道器，所以主要獲取閘道器的MAC地址。如果arp快取記憶體有預設閘道器的MAC地址，直接傳送IP資料包道預設閘道器，再由閘道器轉發到外網；如果arp快取記憶體沒有預設閘道器的MAC地址，還是傳送ARP廣播請求預設閘道器的MAC地址，快取該地址，並且傳送資料包到閘道器。
HTTP協議
HTTP是一個屬於應用層的物件導向的協議，由於其簡捷、快速的方式，適用於分散式超媒體資訊系統。HTTP協議的主要特點可概括如下：
- 支援客戶/伺服器模式。
- 簡單快速：客戶向伺服器請求服務時，只需傳送請求方法和路徑。請求方法常用的有GET、HEAD、POST。每種方法規定了客戶與伺服器聯絡的型別不同。由於HTTP協議簡單，使得HTTP伺服器的程式規模小，因而通訊速度很快。
- 靈活：HTTP允許傳輸任意型別的資料物件。正在傳輸的型別由Content-Type加以標記。
- 無連線：無連線的含義是限制每次連線只處理一個請求。伺服器處理完客戶的請求，並收到客戶的應答後，即斷開連線。採用這種方式可以節省傳輸時間。
- 無狀態：HTTP協議是無狀態協議。無狀態是指協議對於事務處理沒有記憶能力。缺少狀態意味著如果後續處理需要前面的資訊，則它必須重傳，這樣可能導致每次連線傳送的資料量增大。另一方面，在伺服器不需要先前資訊時它的應答就較快。
TCP三次握手和四次揮手的全過程
三次握手：(我要和你建立連結，你真的要和我建立連結麼，我真的要和你建立連結，成功)
- 第一次握手：客戶端傳送syn包(syn=x)到伺服器，並進入SYN_SEND狀態，等待伺服器確認；
- 第二次握手：伺服器收到syn包，必須確認客戶的SYN（ack=x+1），同時自己也傳送一個SYN包（syn=y），即SYN+ACK包，此時伺服器進入SYN_RECV狀態；
- 第三次握手：客戶端收到伺服器的SYN＋ACK包，向伺服器傳送確認包ACK(ack=y+1)，此包傳送完畢，客戶端和伺服器進入ESTABLISHED狀態，完成三次握手。
握手過程中傳送的包裡不包含資料，三次握手完畢後，客戶端與伺服器才正式開始傳送資料。理想狀態下，TCP連線一旦建立，在通訊雙方中的任何一方主動關閉連線之前，TCP 連線都將被一直保持下去。
四次揮手：(我要和你斷開連結；好的，斷吧。我也要和你斷開連結；好的，斷吧)：
- 第一次揮手：客戶端主動關閉方傳送一個FIN，用來關閉客戶端到服務端的資料傳送，也就是客戶端告訴服務端：我已經不會再給你發資料了(當然，在fin包之前傳送出去的資料，如果沒有收到對應的ack確認報文，客戶端依然會重發這些資料)，但是，此時客戶端還可以接受資料。
- 第二次揮手：服務端收到FIN包後，傳送一個ACK給客戶端，確認序號為收到序號+1（與SYN相同，一個FIN佔用一個序號）。
- 第三次揮手：服務端傳送一個FIN，用來關閉服務端到客戶端的資料傳送，也就是告訴客戶端，我的資料也傳送完了，不會再給你發資料了。
- 第四次揮手：客戶端收到FIN後，傳送一個ACK給服務端，確認序號為收到序號+1，至此，完成四次揮手。
第3次握手失敗會怎麼辦?
第三次失敗，只有客戶端處於成功狀態（因為第2次伺服器返回了ACK），伺服器端沒有接收到客戶端的 ACK。 這要分幾種情況討論：
- In other words, if the ACK is dropped but the next packet is not dropped, then everything is fine. 也就是說客戶端發出的 ACK 丟失了，發出的 下一個資料包 沒有丟失，則服務端接收到下一個資料包（這個資料包裡也會帶上 ACK 資訊），能夠進入正常的 ESTABLISHED 狀態
- 如果服務端和客戶端都沒有資料傳送，或者服務端想傳送資料（但是發不了，因為沒有收到客戶端的 ACK），伺服器都會有定時器傳送第二步SYN+ACK資料包，如果客戶端再次傳送ACK成功，建立連線。
- 如果一直不成功，伺服器肯定會有超時設定，超時之後會給客戶端發RTS報文，進入CLOSED狀態，防止SYN洪泛攻擊。
為什麼TCP連結需要三次握手，兩次不可以麼，為什麼？
為了防止已失效的連結請求報文突然又傳送到了服務端，因而產生錯誤。 客戶端發出的連線請求報文並未丟失，而是在某個網路節點長時間滯留了，以致延誤到連結釋放以後的某個時間才到達Server。這是，Server誤以為這是Client發出的一個新的連結請求，於是就向客戶端傳送確認資料包，同意建立連結。若不採用“三次握手”，那麼只要Server發出確認資料包，新的連結就建立了。由於client此時並未發出建立連結的請求，所以其不會理睬Server的確認，也不與Server通訊；而這時Server一直在等待Client的請求，這樣Server就白白浪費了一定的資源。若採用“三次握手”，在這種情況下，由於Server端沒有收到來自客戶端的確認，則就會知道Client並沒有要求建立請求，就不會建立連結。
為什麼連線的時候是三次握手，關閉的時候卻是四次握手?
TCP是全雙工模式，關閉連線時，當主機B收到主機A的FIN報文時，僅僅表示主機 A不再傳送資料了但是還能接收資料。此時，主機B也未必全部資料都傳送給A了，所以B可以立即close；也可以傳送一些資料給A後，再傳送FIN報文給對方來表示同意現在關閉連線，因此，主機BACK和FIN一般都會分開傳送。
TCP的擁塞處理
計算機網路中的頻寬、交換結點中的快取及處理機等都是網路的資源。在某段時間，若對網路中某一資源的需求超過了該資源所能提供的可用部分，網路的效能就會變壞，這種情況就叫做擁塞。擁塞控制就是防止過多的資料注入網路中，這樣可以使網路中的路由器或鏈路不致過載。注意，擁塞控制和流量控制不同，前者是一個全域性性的過程，而後者指點對點通訊量的控制。擁塞控制的方法主要有以下四種：
-
慢啟動：不要一開始就傳送大量的資料，先探測一下網路的擁塞程度，也就是說由小到大逐漸增加擁塞視窗的大小;
-
擁塞避免：擁塞避免演算法讓擁塞視窗緩慢增長，即每經過一個往返時間RTT就把傳送方的擁塞視窗cwnd加1，而不是加倍，這樣擁塞視窗按線性規律緩慢增長。
-
快重傳：快重傳要求接收方在收到一個 失序的報文段 後就立即發出 重複確認（為的是使傳送方及早知道有報文段沒有到達對方）而不要等到自己傳送資料時捎帶確認。快重傳演算法規定，傳送方只要一連收到三個重複確認就應當立即重傳對方尚未收到的報文段，而不必繼續等待設定的重傳計時器時間到期。
-
快恢復：快重傳配合使用的還有快恢復演算法，當傳送方連續收到三個重複確認時，就執行“乘法減小”演算法，把ssthresh門限減半，但是接下去並不執行慢開始演算法：因為如果網路出現擁塞的話就不會收到好幾個重複的確認，所以傳送方現在認為網路可能沒有出現擁塞。所以此時不執行慢開始演算法，而是將cwnd設定為ssthresh的大小，然後執行擁塞避免演算法。
TCP協議如何來保證傳輸的可靠性
TCP提供一種面向連線的、可靠的位元組流服務。其中，面向連線意味著兩個使用TCP的應用（通常是一個客戶和一個伺服器）在彼此交換資料之前必須先建立一個TCP連線。在一個TCP連線中，僅有兩方進行彼此通訊；而位元組流服務意味著兩個應用程式通過TCP連結交換8bit位元組構成的位元組流，TCP不在位元組流中插入記錄識別符號。 對於可靠性，TCP通過以下方式進行保證：
- 資料包校驗：目的是檢測資料在傳輸過程中的任何變化，若校驗出包有錯，則丟棄報文段並且不給出響應，這時TCP傳送資料端超時後會重發資料；
- 對失序資料包重排序：既然TCP報文段作為IP資料包來傳輸，而IP資料包的到達可能會失序，因此TCP報文段的到達也可能會失序。TCP將對失序資料進行重新排序，然後才交給應用層；
- 丟棄重複資料：對於重複資料，能夠丟棄重複資料；
- 應答機制：當TCP收到發自TCP連線另一端的資料，它將傳送一個確認。這個確認不是立即傳送，通常將推遲幾分之一秒；
- 超時重發：當TCP發出一個段後，它啟動一個定時器，等待目的端確認收到這個報文段。如果不能及時收到一個確認，將重發這個報文段；
- 流量控制：TCP連線的每一方都有固定大小的緩衝空間。TCP的接收端只允許另一端傳送接收端緩衝區所能接納的資料，這可以防止較快主機致使較慢主機的緩衝區溢位，這就是流量控制。TCP使用的流量控制協議是可變大小的滑動視窗協議。
從輸入網址到獲得頁面的過程
- 瀏覽器查詢 DNS，獲取域名對應的IP地址:具體過程包括瀏覽器搜尋自身的DNS快取、搜尋作業系統的DNS快取、讀取本地的Host檔案和向本地DNS伺服器進行查詢等。對於向本地DNS伺服器進行查詢，如果要查詢的域名包含在本地配置區域資源中，則返回解析結果給客戶機，完成域名解析(此解析具有權威性)；如果要查詢的域名不由本地DNS伺服器區域解析，但該伺服器已快取了此網址對映關係，則呼叫這個IP地址對映，完成域名解析（此解析不具有權威性）。如果本地域名伺服器並未快取該網址對映關係，那麼將根據其設定發起遞迴查詢或者迭代查詢；
- 瀏覽器獲得域名對應的IP地址以後，瀏覽器向伺服器請求建立連結，發起三次握手；
- TCP/IP連結建立起來後，瀏覽器向伺服器傳送HTTP請求；
- 伺服器接收到這個請求，並根據路徑引數對映到特定的請求處理器進行處理，並將處理結果及相應的檢視返回給瀏覽器；
- 瀏覽器解析並渲染檢視，若遇到對js檔案、css檔案及圖片等靜態資源的引用，則重複上述步驟並向伺服器請求這些資源；
- 瀏覽器根據其請求到的資源、資料渲染頁面，最終向使用者呈現一個完整的頁面。
Session 與 Cookie 的對比
實現機制：Session的實現常常依賴於Cookie機制，通過Cookie機制回傳SessionID； 大小限制：Cookie有大小限制並且瀏覽器對每個站點也有cookie的個數限制，Session沒有大小限制，理論上只與伺服器的記憶體大小有關； 安全性：Cookie存在安全隱患，通過攔截或本地檔案找得到cookie後可以進行攻擊，而Session由於儲存在伺服器端，相對更加安全； 伺服器資源消耗：Session是儲存在伺服器端上會存在一段時間才會消失，如果session過多會增加伺服器的壓力。 Application（ServletContext）：與一個Web應用程式相對應，為應用程式提供了一個全域性的狀態，所有客戶都可以使用該狀態。
交換機和路由器分別的實現原理是什麼？分別在哪個層次上面實現的？
交換機用於區域網，利用主機的MAC地址進行資料傳輸，而不需要關心IP資料包中的IP地址，它工作於資料鏈路層。路由器識別網路是通過IP資料包中IP地址的網路號進行的，所以為了保證資料包路由的正確性，每個網路都必須有一個唯一的網路號。路由器通過IP資料包的IP地址進行路由的（將資料包遞交給哪個下一跳路由器）。路由器工作於網路層。由於裝置現在的發展，現在很多裝置既具有交換又具有路由功能，兩者的界限越來越模糊。
TCP和UDP的區別
- TCP的優點： 可靠，穩定 TCP的可靠體現在TCP在傳遞資料之前，會有三次握手來建立連線，而且在資料傳遞時，有確認、視窗、重傳、擁塞控制機制，在資料傳完後，還會斷開連線用來節約系統資源。 TCP的缺點： 慢，效率低，佔用系統資源高，易被攻擊 TCP在傳遞資料之前，要先建連線，這會消耗時間，而且在資料傳遞時，確認機制、重傳機制、擁塞控制機制等都會消耗大量的時間，而且要在每臺裝置上維護所有的傳輸連線，事實上，每個連線都會佔用系統的CPU、記憶體等硬體資源。 而且，因為TCP有確認機制、三次握手機制，這些也導致TCP容易被人利用，實現DOS、DDOS、CC等攻擊。
- UDP的優點：快，比TCP稍安全 UDP沒有TCP的握手、確認、視窗、重傳、擁塞控制等機制，UDP是一個無狀態的傳輸協議，所以它在傳遞資料時非常快。沒有TCP的這些機制，UDP較TCP被攻擊者利用的漏洞就要少一些。但UDP也是無法避免攻擊的，比如：UDP Flood攻擊…… UDP的缺點： 不可靠，不穩定 因為UDP沒有TCP那些可靠的機制，在資料傳遞時，如果網路質量不好，就會很容易丟包。 基於上面的優缺點，那麼： 什麼時候應該使用TCP： 當對網路通訊質量有要求的時候，比如：整個資料要準確無誤的傳遞給對方，這往往用於一些要求可靠的應用，比如HTTP、HTTPS、FTP等傳輸檔案的協議，POP、SMTP等郵件傳輸的協議。 在日常生活中，常見使用TCP協議的應用如下： 瀏覽器，用的HTTP FlashFXP，用的FTP Outlook，用的POP、SMTP Putty，用的Telnet、SSH QQ檔案傳輸 ………… 什麼時候應該使用UDP： 當對網路通訊質量要求不高的時候，要求網路通訊速度能儘量的快，這時就可以使用UDP。 比如，日常生活中，常見使用UDP協議的應用如下： QQ語音 QQ視訊 TFTP …… 有些應用場景對可靠性要求不高會用到UPD，比如長視訊，要求速率
| TCP | UDP | |
|---|---|---|
| 連線 | 面向連線 | 面向無連線 |
| 可靠性 | 可靠，無差錯，不丟失，不重複 | 盡最大努力交付，即不保證可靠交付 |
| 模式 | 流模式（位元組流） | 資料包模式（報文） |
| 連線 | 點到點 | 支援一對一，一對多，多對一和多對多的互動通訊 |
| 首部開銷 | 20位元組 | 8個位元組 |
| 邏輯通訊通道 | 全雙工的可靠通道 | 不可靠通道 |
| 速度 | 慢 | 快 |
| 對系統資源要求 | 較多 | 較少 |
HTTP和HTTPS
- HTTP：是網際網路上應用最為廣泛的一種網路協議，是一個客戶端和伺服器端請求和應答的標準（TCP），用於從WWW伺服器傳輸超文字到本地瀏覽器的傳輸協議，它可以使瀏覽器更加高效，使網路傳輸減少。
- HTTPS：是以安全為目標的HTTP通道，簡單講是HTTP的安全版，即HTTP下加入SSL層，HTTPS的安全基礎是SSL，因此加密的詳細內容就需要SSL。
HTTPS協議的主要作用可以分為兩種：一種是建立一個資訊保安通道，來保證資料傳輸的安全；另一種就是確認網站的真實性。
Http和Https的區別
Http協議執行在TCP之上，明文傳輸，客戶端與伺服器端都無法驗證對方的身份；Https是身披SSL(Secure Socket Layer)外殼的Http，執行於SSL上，SSL執行於TCP之上，是新增了加密和認證機制的HTTP。二者之間存在如下不同： 埠不同：Http與Http使用不同的連線方式，用的埠也不一樣，前者是80，後者是443； 資源消耗：和HTTP通訊相比，Https通訊會由於加減密處理消耗更多的CPU和記憶體資源； 開銷：Https通訊需要證書，而證書一般需要向認證機構購買； Https的加密機制是一種共享金鑰加密和公開金鑰加密並用的混合加密機制。
HTTPS採用混合加密機制
由於公有金鑰的機制相對複雜，導致其處理速度相對較慢。於是HTTPS利用了兩者的優勢，採用了混合加密的機制。我們知道，共享（對稱）金鑰未能解決的問題是如何能夠安全地把金鑰傳送給對方。只要解決了這個問題就可以進行安全地通訊。於是，HTTPS首先是通過公有金鑰來對共享金鑰進行加密傳輸。當共享金鑰安全地傳輸給對方後，雙方則使用共享金鑰的方式來加密報文，以此來提高傳輸的效率。
HTTPS的優點
儘管HTTPS並非絕對安全，掌握根證書的機構、掌握加密演算法的組織同樣可以進行中間人形式的攻擊，但HTTPS仍是現行架構下最安全的解決方案，主要有以下幾個好處： （1）使用HTTPS協議可認證使用者和伺服器，確保資料傳送到正確的客戶機和伺服器； （2）HTTPS協議是由SSL+HTTP協議構建的可進行加密傳輸、身份認證的網路協議，要比http協議安全，可防止資料在傳輸過程中不被竊取、改變，確保資料的完整性。 （3）HTTPS是現行架構下最安全的解決方案，雖然不是絕對安全，但它大幅增加了中間人攻擊的成本。 （4）谷歌曾在2014年8月份調整搜尋引擎演算法，並稱“比起同等HTTP網站，採用HTTPS加密的網站在搜尋結果中的排名將會更高”。
HTTPS的缺點
雖然說HTTPS有很大的優勢，但其相對來說，還是存在不足之處的： （1）HTTPS協議握手階段比較費時，會使頁面的載入時間延長近50%，增加10%到20%的耗電； （2）HTTPS連線快取不如HTTP高效，會增加資料開銷和功耗，甚至已有的安全措施也會因此而受到影響； （3）SSL證書需要錢，功能越強大的證書費用越高，個人網站、小網站沒有必要一般不會用。 （4）SSL證書通常需要繫結IP，不能在同一IP上繫結多個域名，IPv4資源不可能支撐這個消耗。 （5）HTTPS協議的加密範圍也比較有限，在黑客攻擊、拒絕服務攻擊、伺服器劫持等方面幾乎起不到什麼作用。最關鍵的，SSL證書的信用鏈體系並不安全，特別是在某些國家可以控制CA根證書的情況下，中間人攻擊一樣可行。
socket
socket是通訊的基石。支援TCP/IP等協議的基本操作單元。 應用層通過傳輸層進行資料通訊時，TCP會遇到同時為多個應用程式程式提供併發服務的問題。多個TCP連線或多個應用程式程式可能需要通過同一個TCP協議埠傳輸資料。為了區別不同的應用程式程式和連線，許多計算機作業系統為應用程式與TCP／IP協議互動提供了套接字(Socket)介面。應用層可以和傳輸層通過Socket介面，區分來自不同應用程式程式或網路連線的通訊，實現資料傳輸的併發服務。
參考
計算機網路之面試常考 面試/筆試第一彈 —— 計算機網路面試問題集錦
獲取更多最新資訊，免費獲取百G視訊教程 請關注微信公眾號：南強說晚安
我在參加掘金技術徵文 徵文活動地址