一 OSI七層模型

OSI七層協(xié)議模型以及個(gè)模型協(xié)議

• OSI七層協(xié)議模型主要是：應(yīng)用層（Application）、表示層（Presentation）、會話層（Session）、傳輸層（Transport）、網(wǎng)絡(luò)層（Network）、數(shù)據(jù)鏈路層（Data Link）、物理層（Physical）。

  
  
  osi-1

二 五層體系結(jié)構(gòu)

五層體系結(jié)構(gòu)包括：應(yīng)用層、運(yùn)輸層、網(wǎng)絡(luò)層、數(shù)據(jù)鏈路層和物理層。
五層協(xié)議只是OSI和TCP/IP的綜合，實(shí)際應(yīng)用還是TCP/IP的四層結(jié)構(gòu)。為了方便可以把下兩層稱為網(wǎng)絡(luò)接口層。

tcp-ip

三 TCP,UDP 協(xié)議的區(qū)別

• UDP 在傳送數(shù)據(jù)之前不需要先建立連接，遠(yuǎn)地主機(jī)在收到 UDP 報(bào)文后，不需要給出任何確認(rèn)。雖然 UDP 不提供可靠交付，但在某些情況下 UDP 確是一種最有效的工作方式（一般用于即時(shí)通信），比如： QQ 語音、 QQ 視頻 、直播等等
• TCP 提供面向連接的服務(wù)。在傳送數(shù)據(jù)之前必須先建立連接，數(shù)據(jù)傳送結(jié)束后要釋放連接。 TCP 不提供廣播或多播服務(wù)。由于 TCP 要提供可靠的，面向連接的傳輸服務(wù)（TCP的可靠體現(xiàn)在TCP在傳遞數(shù)據(jù)之前，會有三次握手來建立連接，而且在數(shù)據(jù)傳遞時(shí)，有確認(rèn)、窗口、重傳、擁塞控制機(jī)制，在數(shù)據(jù)傳完后，還會斷開連接用來節(jié)約系統(tǒng)資源），這一難以避免增加了許多開銷，如確認(rèn)，流量控制，計(jì)時(shí)器以及連接管理等。這不僅使協(xié)議數(shù)據(jù)單元的首部增大很多，還要占用許多處理機(jī)資源。TCP 一般用于文件傳輸、發(fā)送和接收郵件、遠(yuǎn)程登錄等場景。

四 TCP 協(xié)議如何保證可靠傳輸

1. 應(yīng)用數(shù)據(jù)被分割成 TCP 認(rèn)為最適合發(fā)送的數(shù)據(jù)塊。
2. TCP 給發(fā)送的每一個(gè)包進(jìn)行編號，接收方對數(shù)據(jù)包進(jìn)行排序，把有序數(shù)據(jù)傳送給應(yīng)用層。
3. 校驗(yàn)和： TCP 將保持它首部和數(shù)據(jù)的檢驗(yàn)和。這是一個(gè)端到端的檢驗(yàn)和，目的是檢測數(shù)據(jù)在傳輸過程中的任何變化。如果收到段的檢驗(yàn)和有差錯(cuò)，TCP 將丟棄這個(gè)報(bào)文段和不確認(rèn)收到此報(bào)文段。
4. TCP 的接收端會丟棄重復(fù)的數(shù)據(jù)。
5. 流量控制： TCP 連接的每一方都有固定大小的緩沖空間，TCP的接收端只允許發(fā)送端發(fā)送接收端緩沖區(qū)能接納的數(shù)據(jù)。當(dāng)接收方來不及處理發(fā)送方的數(shù)據(jù)，能提示發(fā)送方降低發(fā)送的速率，防止包丟失。TCP 使用的流量控制協(xié)議是可變大小的滑動窗口協(xié)議。 （TCP 利用滑動窗口實(shí)現(xiàn)流量控制）
6. 擁塞控制： 當(dāng)網(wǎng)絡(luò)擁塞時(shí)，減少數(shù)據(jù)的發(fā)送。
7. ARQ協(xié)議： 也是為了實(shí)現(xiàn)可靠傳輸?shù)?，它的基本原理就是每發(fā)完一個(gè)分組就停止發(fā)送，等待對方確認(rèn)。在收到確認(rèn)后再發(fā)下一個(gè)分組。
8. 超時(shí)重傳： 當(dāng) TCP 發(fā)出一個(gè)段后，它啟動一個(gè)定時(shí)器，等待目的端確認(rèn)收到這個(gè)報(bào)文段。如果不能及時(shí)收到一個(gè)確認(rèn)，將重發(fā)這個(gè)報(bào)文段。

4.1 ARQ協(xié)議

自動重傳請求（Automatic Repeat-Request，ARQ）是OSI模型中數(shù)據(jù)鏈路層和傳輸層的錯(cuò)誤糾正協(xié)議之一。它通過使用確認(rèn)和超時(shí)這兩個(gè)機(jī)制，在不可靠服務(wù)的基礎(chǔ)上實(shí)現(xiàn)可靠的信息傳輸。如果發(fā)送方在發(fā)送后一段時(shí)間之內(nèi)沒有收到確認(rèn)幀，它通常會重新發(fā)送。ARQ包括 : 停止等待ARQ協(xié)議 和 連續(xù)ARQ協(xié)議。

4.1.1 停止等待ARQ協(xié)議

• 停止等待協(xié)議是為了實(shí)現(xiàn)可靠傳輸?shù)?，它的基本原理就是每發(fā)完一個(gè)分組就停止發(fā)送，等待對方確認(rèn)（回復(fù)ACK）。如果過了一段時(shí)間（超時(shí)時(shí)間后，因此每發(fā)送完一個(gè)分組需要設(shè)置一個(gè)超時(shí)計(jì)時(shí)器），還是沒有收到 ACK 確認(rèn)，說明沒有發(fā)送成功，需要重新發(fā)送，直到收到確認(rèn)后再發(fā)下一個(gè)分組；
• 在停止等待協(xié)議中，若接收方收到重復(fù)分組，就丟棄該分組，但同時(shí)還要發(fā)送確認(rèn)；
  優(yōu)點(diǎn)： 簡單；
  缺點(diǎn)： 信道利用率低，等待時(shí)間長；

1. 無差錯(cuò)情況:
   發(fā)送方發(fā)送分組,接收方在規(guī)定時(shí)間內(nèi)收到,并且回復(fù)確認(rèn).發(fā)送方再次發(fā)送。
2. 出現(xiàn)差錯(cuò)情況（超時(shí)重傳）:
   停止等待協(xié)議中超時(shí)重傳是指只要超過一段時(shí)間仍然沒有收到確認(rèn)，就重傳前面發(fā)送過的分組（認(rèn)為剛才發(fā)送過的分組丟失了）。因此每發(fā)送完一個(gè)分組需要設(shè)置一個(gè)超時(shí)計(jì)時(shí)器，其重傳時(shí)間應(yīng)比數(shù)據(jù)在分組傳輸?shù)钠骄禃r(shí)間更長一些。這種自動重傳方式常稱為 自動重傳請求 ARQ 。另外在停止等待協(xié)議中若收到重復(fù)分組，就丟棄該分組，但同時(shí)還要發(fā)送確認(rèn)。連續(xù) ARQ 協(xié)議 可提高信道利用率。發(fā)送維持一個(gè)發(fā)送窗口，凡位于發(fā)送窗口內(nèi)的分組可連續(xù)發(fā)送出去，而不需要等待對方確認(rèn)。接收方一般采用累積確認(rèn)，對按序到達(dá)的最后一個(gè)分組發(fā)送確認(rèn)，表明到這個(gè)分組位置的所有分組都已經(jīng)正確收到了。
3. 確認(rèn)丟失和確認(rèn)遲到

• 確認(rèn)丟失：
  確認(rèn)消息在傳輸過程丟失當(dāng)A發(fā)送M1消息，B收到后，B向A發(fā)送了一個(gè)M1確認(rèn)消息，但卻在傳輸過程中丟失。而A并不知道，在超時(shí)計(jì)時(shí)過后，A重傳M1消息，B再次收到該消息后采取以下兩點(diǎn)措施：

1.  丟棄這個(gè)重復(fù)的M1消息，不向上層交付。
2.  向A發(fā)送確認(rèn)消息。（不會認(rèn)為已經(jīng)發(fā)送過了，就不再發(fā)送。A能重傳，就證明B的確認(rèn)消息丟失）。

• 確認(rèn)遲到 ：
  確認(rèn)消息在傳輸過程中遲到 A發(fā)送M1消息，B收到并發(fā)送確認(rèn)。在超時(shí)時(shí)間內(nèi)沒有收到確認(rèn)消息，A重傳M1消息，B仍然收到并繼續(xù)發(fā)送確認(rèn)消息（B收到了2份M1）。此時(shí)A收到了B第二次發(fā)送的確認(rèn)消息。接著發(fā)送其他數(shù)據(jù)。過了一會，A收到了B第一次發(fā)送的對M1的確認(rèn)消息（A也收到了2份確認(rèn)消息）。處理如下：

1.  A收到重復(fù)的確認(rèn)后，直接丟棄。
2.  B收到重復(fù)的M1后，也直接丟棄重復(fù)的M1。

4.1.2 連續(xù)ARQ協(xié)議

連續(xù) ARQ 協(xié)議可提高信道利用率。發(fā)送方維持一個(gè)發(fā)送窗口，凡位于發(fā)送窗口內(nèi)的分組可以連續(xù)發(fā)送出去，而不需要等待對方確認(rèn)。接收方一般采用累計(jì)確認(rèn)，對按序到達(dá)的最后一個(gè)分組發(fā)送確認(rèn)，表明到這個(gè)分組為止的所有分組都已經(jīng)正確收到了。
優(yōu)點(diǎn)： 信道利用率高，容易實(shí)現(xiàn)，即使確認(rèn)丟失，也不必重傳。
缺點(diǎn)： 不能向發(fā)送方反映出接收方已經(jīng)正確收到的所有分組的信息。 比如：發(fā)送方發(fā)送了 5條 消息，中間第三條丟失（3號），這時(shí)接收方只能對前兩個(gè)發(fā)送確認(rèn)。發(fā)送方無法知道后三個(gè)分組的下落，而只好把后三個(gè)全部重傳一次。這也叫 Go-Back-N（回退 N），表示需要退回來重傳已經(jīng)發(fā)送過的 N 個(gè)消息。

五 HTTP 1.0和HTTP 1.1的主要區(qū)別是什么?

1. 長連接 : 在HTTP/1.0中，默認(rèn)使用的是短連接，也就是說每次請求都要重新建立一次連接。HTTP 是基于TCP/IP協(xié)議的,每一次建立或者斷開連接都需要三次握手四次揮手的開銷，如果每次請求都要這樣的話，開銷會比較大。因此最好能維持一個(gè)長連接，可以用個(gè)長連接來發(fā)多個(gè)請求。HTTP 1.1起，默認(rèn)使用長連接 ,默認(rèn)開啟Connection： keep-alive。 HTTP/1.1的持續(xù)連接有非流水線方式和流水線方式 。流水線方式是客戶在收到HTTP的響應(yīng)報(bào)文之前就能接著發(fā)送新的請求報(bào)文。與之相對應(yīng)的非流水線方式是客戶在收到前一個(gè)響應(yīng)后才能發(fā)送下一個(gè)請求。
2. 錯(cuò)誤狀態(tài)響應(yīng)碼 :在HTTP1.1中新增了24個(gè)錯(cuò)誤狀態(tài)響應(yīng)碼，如409（Conflict）表示請求的資源與資源的當(dāng)前狀態(tài)發(fā)生沖突；410（Gone）表示服務(wù)器上的某個(gè)資源被永久性的刪除。
3. 緩存處理 :在HTTP1.0中主要使用header里的If-Modified-Since,Expires來做為緩存判斷的標(biāo)準(zhǔn)，HTTP1.1則引入了更多的緩存控制策略例如Entity tag，If-Unmodified-Since, If-Match, If-None-Match等更多可供選擇的緩存頭來控制緩存策略。
4. 帶寬優(yōu)化及網(wǎng)絡(luò)連接的使用 :HTTP1.0中，存在一些浪費(fèi)帶寬的現(xiàn)象，例如客戶端只是需要某個(gè)對象的一部分，而服務(wù)器卻將整個(gè)對象送過來了，并且不支持?jǐn)帱c(diǎn)續(xù)傳功能，HTTP1.1則在請求頭引入了range頭域，它允許只請求資源的某個(gè)部分，即返回碼是206（Partial Content），這樣就方便了開發(fā)者自由的選擇以便于充分利用帶寬和連接。

HTTP 和 HTTPS 的區(qū)別？

1. 端口 ：HTTP的URL由“http://”起始且默認(rèn)使用端口80，而HTTPS的URL由“https://”起始且默認(rèn)使用端口443。
2. 安全性和資源消耗： HTTP協(xié)議運(yùn)行在TCP之上，所有傳輸?shù)膬?nèi)容都是明文，客戶端和服務(wù)器端都無法驗(yàn)證對方的身份。HTTPS是運(yùn)行在SSL/TLS之上的HTTP協(xié)議，SSL/TLS 運(yùn)行在TCP之上。所有傳輸?shù)膬?nèi)容都經(jīng)過加密，加密采用對稱加密，但對稱加密的密鑰用服務(wù)器方的證書進(jìn)行了非對稱加密。所以說，HTTP 安全性沒有 HTTPS高，但是 HTTPS 比HTTP耗費(fèi)更多服務(wù)器資源。
   • 對稱加密：密鑰只有一個(gè)，加密解密為同一個(gè)密碼，且加解密速度快，典型的對稱加密算法有DES、AES等；
   • 非對稱加密：密鑰成對出現(xiàn)（且根據(jù)公鑰無法推知私鑰，根據(jù)私鑰也無法推知公鑰），加密解密使用不同密鑰（公鑰加密需要私鑰解密，私鑰加密需要公鑰解密），相對對稱加密速度較慢，典型的非對稱加密算法有RSA、DSA等。