網絡常見問題合集

麪筋分類彙總-測開向

• 7層/5層/4層網絡

  • 網絡七層有哪些：物理層，數據鏈路層，網絡層，傳輸層，(會話層，表示層)，應用層
  • 各層的協議：重點關注應用層、網絡層、傳輸層。
    • 會話層，表示層：沒有協議
    • 傳輸層：tcp，udp
    • 網絡層：arp，ip
    • 應用層：http，ftp，smtp，dns

• OSI分層 （7層）：

  • 物理層、數據鏈路層、網絡層、傳輸層、會話層、表示層、應用層。
  • 是一個邏輯上的定義，一個規範，它把網絡從邏輯上分爲了7層。每一層都有相關、相對應的物理設備，好比路由器，交換機。
  • OSI 七層模型是一種框架性的設計方法 ，創建七層模型的主要目的是爲解決異種網絡互連時所遇到的兼容性問題，其主要的功能使就是幫助不一樣類型的主機實現數據傳輸。

• TCP/IP分層（4層）：

  • 網絡接口層、 網際層、運輸層、 應用層。
  • 主要針對協議。

• 五層協議 （5層）：

  • 物理層、數據鏈路層、網絡層、運輸層、 應用層。
  • 綜合了7層和4層的優缺點進行折中的分層方式，同時爲了方便學習計算機網絡原理而採用的。

• 每一層的協議以下

  • 物理層：RJ4五、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

• 7層網絡結構的每一層的做用以下：

  • 物理層：經過媒介傳輸比特,肯定機械及電氣規範（比特Bit）
  • 數據鏈路層：將比特組裝成幀和點到點的傳遞（幀Frame）
  • 網絡層：負責數據包從源到宿的傳遞和網際互連（包PackeT）
  • 傳輸層：提供端到端的可靠報文傳遞和錯誤恢復（段Segment）
  • 會話層：創建、管理和終止會話（會話協議數據單元SPDU）
  • 表示層：對數據進行翻譯、加密和壓縮（表示協議數據單元PPDU）
  • 應用層：容許訪問OSI環境的手段（應用協議數據單元APDU）

• tcp三次握手和四次揮手 & 爲何須要這麼屢次

  • tcp, udp：傳輸層
  • 三次握手-服務器易受SYN洪泛攻擊：
    • 服務器端的資源是第二次握手時分配的，而客戶端的資源是在完成第三次握手時分配的。
  • 三次握手：創建鏈接。
    • 緣由：爲了防止已失效的鏈接請求報文段忽然又傳送到了服務端，於是產生錯誤。網絡故障時，若是沒有三次握手就創建鏈接容易致使錯誤。
  • 四次揮手：終止鏈接。
    • 緣由：TCP協議是一種面向鏈接的、可靠的、基於字節流的運輸層通訊協議。TCP是全雙工模式，這就意味着，當 Client 發出FIN報文段時，只是表示 Client 已經沒有數據要發送了，Client 告訴 Server，它的數據已經所有發送完畢了；可是，這個時候 Client 仍是能夠接受來自 Server 的數據；當 Server 返回ACK報文段時，表示它已經知道 Client 沒有數據發送了，可是 Server 仍是能夠發送數據到 Client 的；當 Server 也發送了FIN報文段時，這個時候就表示 Server 也沒有數據要發送了，就會告訴 Client ，我也沒有數據要發送了，以後彼此就會愉快的中斷此次TCP鏈接。若是要正確的理解四次分手的原理，就須要瞭解四次分手過程當中的狀態變化。

• tcp和udp

  • TCP提供面向鏈接的、可靠的數據流傳輸，UDP提供的是非面向鏈接的、不可靠的數據流傳輸。
    • tcp：提供可靠交付的服務(無差錯，不丟失，不重複，且按序到達)(校驗和、重傳控制、序號標識、滑動窗口、確認應答實現可靠傳輸。如丟包時的重發控制，還能夠對次序亂掉的分包進行順序控制。)。
    • udp：盡最大努力交付(不保證可靠交付)。
  • TCP傳輸單位稱爲TCP報文段，UDP傳輸單位稱爲用戶數據報。
    • TCP面向字節流，UDP面向報文。
  • TCP傳送數據以前創建鏈接，傳送結束後釋放鏈接，UDP傳送數據以前不創建鏈接，收到後不給出任何確認。
  • TCP適用於大文件，UDP適用於小文件。
  • 每一條TCP鏈接只能是點對點的（一對一），UDP支持一對1、一對多、多對一和多對多的交互通訊。
    • TCP提供全雙工通訊，UDP無擁塞控制。
  • TCP注重數據安全性，傳輸慢；UDP數據傳輸快，可是其安全性卻通常。
  • TCP對應的協議和UDP對應的協議不一樣。
    • TCP：HTTP，ftp，smtp(郵件傳送協議)，pop3
    • UDP：DNS(域名解析)，SNMP(簡單網絡管理協議)，TFTP(簡單文件傳輸協議)
  • 丟包：
    • 採用TCP，一旦發生丟包，TCP會將後續的包緩存起來，等前面的包重傳並接收到後再繼續發送，延時會愈來愈大。
    • UDP對實時性要求較爲嚴格的狀況下，採用自定義重傳機制，可以把丟包產生的延遲降到最低，儘可能減小網絡問題對遊戲性形成影響。

• 視頻面試用的是TCP仍是UDP

  • udp：沒有擁塞控制，強調實時性。
  • UDP 沒有擁塞控制，一直會以恆定的速度發送數據。即便網絡條件很差，也不會對發送速率進行調整。
  • 這樣實現的弊端就是在網絡條件很差的狀況下可能會致使丟包，可是優勢也很明顯，在某些實時性要求高的場景（好比電話會議）就須要使用 UDP 而不是 TCP。

• 應用層協議

  • 域名系統DNS：（輸入網址顯示網站主頁，非鏈接，可能收不到）UDP鏈接，端口53
  • 文件傳輸協議FTP：（交做業系統，保證做業已提交）TCP鏈接，端口21
    • 注：簡單文件傳輸協議TFTP：（發送一條聊天「在嗎？」，沒必要保證必須收到）UDP鏈接，用於傳送小文件。
  • 簡單郵件傳送協議SMTP：（收發郵件，要保證送到）TCP鏈接，端口25，客戶/服務器（C/S）
    • SMTP的三個階段：創建鏈接 -- 郵件傳送 -- 鏈接釋放
  • 多用途網際郵件擴充MIME:
    • 針對SMTP的缺點進行優化，使得傳輸內容豐富多彩。
    • SMTP的缺點：傳送僅限於7位ASCII碼，不能傳送其餘國家文字，不能傳送可執行文件、二進制文件，對長度有限制等。
  • 郵件協議POP3：TCP鏈接，端口110，客戶/服務器（C/S）；兩種工做方式：下載並保留，下載並刪除。
  • 網際報文存取協議IMAP：比POP3更復雜，能夠先看首部，須要下載時再下載到用戶計算機等。
  • 基於萬維網的電子郵件：關聯用戶的部分改成HTTP，郵件服務器交互仍是SMTP

• 怎麼讓udp實現可靠鏈接

  • TCP如何實現可靠性傳輸？ 校驗，序號，確認機制、重傳機制、滑動窗口。
    • 確認重傳不分家
    • 重傳：超時和冗餘ACK
  • UDP實現可靠鏈接：最簡單的方式是在應用層模仿傳輸層TCP的可靠性傳輸。
    • 一、添加seq/ack機制，確保數據發送到對端
    • 二、添加發送和接收緩衝區，主要是用戶超時重傳。
    • 三、添加超時重傳機制。

• TCP流量控制

  • tcp提供一種基於滑動窗口協議的流量控制機制。滑動窗口動態變化。
    • 接收方的接受窗口rwnd告訴發送方，本身所接受的緩存大小。
    • 發送方的擁塞窗口swnd根據當前網絡的擁塞狀態肯定窗口值。
  • 在rwnd爲0後，從新開始傳遞數據但rwnd數據丟失時，容易引起A、B主機相互等待的死鎖局面：
    • 解決：探測報文段+持續計時器。
    • 一方收到零窗口通知時，啓動持續計時器，時間到後發送探測報文段，還是0時，重置持續計時器。

• TCP擁塞控制和快重傳

  • 擁塞控制：
    • 防止過多數據注入網絡，以使網絡中的路由器或鏈路不致過載。
    • 出現擁塞的條件：對資源需求的總和>可用資源。
  • 擁塞控制與流量控制：
    • 擁塞控制：全局性；流量控制：點對點。
  • 擁塞控制的算法：慢開始、擁塞避免，快重傳，快恢復。
  • 慢開始和擁塞避免：慢開始 -- 擁塞避免算法 -- 網絡擁塞的處理 -- 慢開始 -- 擁塞避免算法 -- ...
    • 慢開始：擁塞窗口cwnd從1開始，指數增大，直到慢開始門限ssthread，以後改用擁塞避免算法。
    • 擁塞避免：加法增長，乘法減少 -- 擁塞窗口每次增長1，直到一次超時即網絡擁塞時，而後門限ssthread減少爲當前cwnd的一半
    • 網絡擁塞的處理：ssthread更新後，擁塞窗口減少爲1，並從新開始慢開始階段。
  • 快重傳和快恢復：慢開始 -- 快重傳 -- （跳過慢開始）快恢復 -- 擁塞避免 --
    • 快重傳：使用了冗餘ACK來檢查丟包的發生。當發送方連續收到三個重複的ACK報文時，直接重傳對方還沒有收到的報文段，而沒必要等待重傳計時器超時。
    • 快恢復：當發送端收到連續三個冗餘ACK（即重複確認）時，先乘法減少，把慢開始門限ssthread減少爲出現擁塞時發送方cwnd的一半；而後跳過cwnd=1起始的慢開始過程，而是將cwnd的值設置爲慢開始門限ssthread改變後的值，而後開始執行擁塞避免算法（加法增大）。
  • 綜述：
    • 擁塞控制中，發送方發送窗口的大小 = min（接收端窗口rwnd， 擁塞窗口cwnd）
    • 慢開始、擁塞避免、快重傳、快恢復是同時應用在擁塞控制機制之中的
      • 當發送方檢測到超時：慢開始和擁塞避免；
      • 當發送方接受到冗餘ACK時：快重傳和快恢復。

• HTTP和HTTPS

  • 小結：證書；明文暗文；鏈接方式；端口；鏈接狀態等。
  • https協議須要到CA（Certificate Authority，證書頒發機構）申請證書，通常免費證書較少，於是須要必定費用。
  • http是超文本傳輸協議，信息是明文傳輸，https則是具備安全性的ssl加密傳輸協議。
  • http和https使用的是徹底不一樣的鏈接方式，用的端口也不同，前者是80，後者是443。
  • http的鏈接很簡單，是無狀態的。Https協議是由SSL+Http協議構建的可進行加密傳輸、身份認證的網絡協議，比http協議安全。
    • (無狀態的意思是其數據包的發送、傳輸和接收都是相互獨立的。無鏈接的意思是指通訊雙方都不長久的維持對方的任何信息。)

• HTTP請求行、請求頭、請求體

  • HTTP請求報文由3部分組成（請求行+請求頭+請求體）：
  • HTTP的響應報文也由三部分組成（響應行+響應頭+響應體）：
  • 請求HTTP報文和響應HTTP報文都擁有若干個報文頭屬性，它們是爲協助客戶端及服務端交互的一些附屬信息
  • 請求頭：說明瀏覽器、服務器和報文主體的一些信息。一般用於說明是誰或什麼在發送請求、請求源於何處，或者客戶端的喜愛及能力。
    • 服務器能夠根據請求頭部給出的客戶端信息，試着爲客戶端提供更好的響應。
    • 請求頭域可能包含下列字段Accept、Accept-Charset、Accept- Encoding、Accept-Language、Authorization、From、Host、If-Modified-Since、If-Match、If-None-Match、If-Range、If-Range、If-Unmodified-Since、Max-Forwards、Proxy-Authorization、Range、Referer、User-Agent。
    • 對請求頭域的擴展要求通信雙方都支持，若是存在不支持的請求頭域，通常將會做爲實體頭域處理。
  • 響應頭向客戶端提供一些額外信息，好比誰在發送響應、響應者的功能，甚至與響應相關的一些特殊指令。
    • 這些頭部有助於客戶端處理響應，並在未來發起更好的請求。
    • 響應頭域包含Age、Location、Proxy-Authenticate、Public、Retry- After、Server、Vary、Warning、WWW-Authenticate。
    • 對響應頭域的擴展要求通信雙方都支持，若是存在不支持的響應頭域，通常將會做爲實體頭域處理。

• HTTP的請求類型和狀態碼

  • http請求方式有哪些：GET、POST、HEAD、PUT、PATCH、DELETE、CONNECT、OPTIONS、TRACE。
  • HTTP1.0和HTTP1.1的區別：
    • HTTP1.0 定義了三種請求方法： GET, POST 和 HEAD方法。
    • HTTP1.1 新增了六種請求方法：OPTIONS、PUT、PATCH、DELETE、TRACE 和 CONNECT 方法。
  • 重定向：經常用於自動跳轉，從活動空間來看大概分兩類：服務器內部跳轉和服務器之間跳轉。
    • 服務器會在須要指示瀏覽器進行重定向的時候返回這些狀態碼給瀏覽器，且大多數3XX狀態碼都會附上Location字段，其中的值則是服務器要求瀏覽器轉向的URL的值。
    • 瀏覽器接受到重定向響應之後，會根據Location字段的值，自動的將請求轉向其中的URL。

• 常見的狀態碼（共33種）：

  • 概述：1** 信息；2** 請求成功；3** 資源重定向；4** 客戶端錯誤；5** 服務器錯誤
  • 100 繼續、200 OK，請求成功，相應成功（get post中發送tcp用到）、
  • 202 已經接受請求，但未處理完成；206 服務器成功處理了部分GET請求
  • 301 永久重定向，資源（網頁等）被永久轉移到其它URL；303 查看其它地址，與301相似，使用GET和POST請求查看
  • 302 臨時重定向，與301相似，但資源只是臨時被移動，客戶端應繼續使用原有URL；307 臨時重定向，與302相似，使用GET請求重定向。
  • 304 未修改，請求的這個資源至你上次取得後，並無更改，你直接用你本地的緩存吧
  • 400 客戶端請求的語法錯誤，服務器沒法理解；401 用戶未受權，請求要求用戶的身份認證
  • 403 資源不可用，服務器理解請求客戶端的請求，可是拒絕執行此請求；404 請求的資源（網頁等）不存在
  • 500 內部服務器錯誤，501 服務器不支持請求的功能，沒法完成請求，
  • 503 服務器不可用，抱歉在忙，因爲超載或系統維護，服務器暫時的沒法處理客戶端的請求。
  • 502 網關錯誤 (Bad gateway)、504 網關超時 Gateway Time-out。

• http中get和post的區別

  • 概述：
    • GET和POST是什麼？HTTP協議中的兩種發送請求的方法。
    • HTTP是基於TCP/IP的萬維網通訊協議，因此GET和POST的底層也是TCP/IP連接。
  • (1)Get方法會將提交的數據放在URL中，即以明文的方式傳遞參數數據； Post方法會將提交的數據放在請求體中
    • URL：以？分割URL地址和傳輸數據，參數間以&相連。eg：http://localhost：8080/.../Login.aspx?name=user&pwd=123456
    • 注：以此爲基礎，get和post產生如下區別，分別從存儲和安全性兩個角度考慮。
  • (2) URL和請求體致使的區別：
    • 數據量：Get方法傳遞的數據量較小，受URL長度限制，最大不超過2KB；Post方法傳遞的數據量較大，通常不受限制，大小取決於服務器的處理能力，（大多數服務器最多處理64K大小的url）
    • 可見性：get是明文傳輸，post的傳輸數據不可見；
    • 參數的數據類型限制：GET是ASCII字符，而POST沒有限制。
    • 緩存：GET請求會被瀏覽器主動cache緩存，而POST不會，除非手動設置。
    • 歷史記錄：GET請求參數會被完整保留在瀏覽器歷史記錄裏，而POST中的參數不會被保留。
    • 收藏書籤：GET產生的URL地址能夠被Bookmark，而POST不能夠
    • 安全性和效率：Get方法安全性低，效率高；Post方法安全性高，效率低（耗時稍長）
    • 後退刷新時：GET在瀏覽器回退時是無害的，而POST數據會被從新提交。
  • (3) tcp數據包：
    • Get方法會產生一個TCP數據包，瀏覽器會把Header和Data一併發送出去，服務器響應200（OK），並回傳相應的數據。
    • Post方法會產生兩個TCP數據包，瀏覽器會先將Header發送出去，服務器響應100（Continue）後，瀏覽器再發送Data，服務器響應200（OK），並回傳相應的數據。

• 無效連接

  • 死連接（Dead Links）指的是無效連接，也就是那些不可到達的連接。
  • 通俗地理解是之前能夠經過點擊這個連接到達網站頁面，後續可能因爲網站遷移、改版或操做不當等緣由，使得連接指向的目標頁面不存在而沒法訪問所遺留的連接，即稱爲死連接。
  • 訪問死連接時，通常會出現「抱歉，您所訪問的頁面不存在」的提示信息或者 404 狀態頁面。

• 死連接 VS 錯誤連接

  • 錯誤連接是因爲用戶的疏忽形成（如用戶不當心輸錯字母等）所請求的連接不存在。
  • 與死連接不一樣的是，錯誤連接是根本不存在的連接，而死連接是本來存在的頁面，因爲站長操做方面的緣由，形成沒法訪問。
  • 形成錯誤連接的緣由以下：
    • 用戶將域名拼寫錯誤。
    • 用戶輸錯 URL 地址。
    • 用戶輸入 URL 時後綴多餘或缺乏斜槓。
    • URL 地址中出現的字母大小寫不徹底匹配。

• 數據傳輸方式

  • 並行串行；同步異步；單工半雙工全雙工

• socket編程

• session與cookies區別，以及分別存儲在什麼地方

  • cookie-客戶端；session-服務器端

  • Cookie和Session

    • cookie：由於HTTP請求是無狀態的，它不會認識當前的用戶是誰。cookie的出現就爲了解決這個問題。用戶第一次請求服務器時，服務器會返回一些數據（cookie）給瀏覽器，瀏覽器保存到本地，等下一次再請求服務器時就會自動帶上本地的cookie數據，服務器拿到這個數據就知道該請求用戶是誰了。可是cookie只能存少許數據，不一樣瀏覽器存儲大小不一樣，但通常不超過4KB。
    • session：session和cookie的做用相似，都是爲了保存用戶相關的信息，可是不一樣的是：session是保存在服務器上的，cookie保存在本地瀏覽器。保存在服務器上的session數據不容易被竊取，更加安全，但弊端是佔用了服務器的資源。

  • session與cookie的聯繫

    • Cookie和Session都是會話技術
    • session是須要藉助cookie才能正常工做的，若是客戶端徹底禁止cookie，session將失效。

  • Cookie和Session的區別

    • 一、Cookie和Session都是會話技術，Cookie是運行在客戶端，Session是運行在服務器端。
    • 二、Cookie有大小限制以及瀏覽器在存cookie的個數也有限制，Session是沒有大小限制
      • 單個cookie保存的數據不能超過4K，不少瀏覽器都限制一個站點最多保存20個cookie。
      • session是沒有大小限制，和服務器的內存大小有關。
    • 三、Cookie有安全隱患，經過攔截或本地文件找獲得你的cookie後能夠進行攻擊。
      • 別人能夠分析存放在本地的cookie並進行cookie欺騙
      • 考慮到安全應當使用session。
    • 四、Session是保存在服務器端上會存在一段時間纔會消失，若是session過多會增長服務器的壓力。
      • 考慮到減輕服務器性能壓力方面，應當使用cookie。
    • 五、session中保存的是對象，cookie中保存的是字符串。

• CDN

• APR協議

  • ARP協議 （在OSI模型中ARP協議屬於鏈路層；而在TCP/IP模型中，ARP協議屬於網絡層。）
    • 地址解析協議，即ARP（Address Resolution Protocol），是根據IP地址獲取物理地址的一個TCP/IP協議。主機發送信息時將包含目標IP地址的ARP請求廣播到局域網絡上的全部主機，並接收返回消息，以此肯定目標的物理地址；收到返回消息後將該IP地址和物理地址存入本機ARP緩存中並保留必定時間，下次請求時直接查詢ARP緩存以節約資源。
    • 地址解析協議是創建在網絡中各個主機互相信任的基礎上的，局域網絡上的主機能夠自主發送ARP應答消息，其餘主機收到應答報文時不會檢測該報文的真實性就會將其記入本機ARP緩存；由此攻擊者就能夠向某一主機發送僞ARP應答報文，使其發送的信息沒法到達預期的主機或到達錯誤的主機，這就構成了一個ARP欺騙。
    • ARP命令可用於查詢本機ARP緩存中IP地址和MAC地址的對應關係、添加或刪除靜態對應關係等。相關協議有RARP、代理ARP。NDP用於在IPv6中代替地址解析協議。
  • 其餘
    • ARP分層的位置是TCP/IP的網絡層
    • ARP報文是由以太網幀進行封裝傳輸的，沒有封裝進IP包
    • 實際上，對網絡接口層的以太網幀來說，它們一樣是幀的上層協議，當收到以太幀時，根據幀的協議字段判斷是送到ARP仍是IP
    • 之因此不把它放在數據鏈路層，是由於它並不具有數據鏈路層的功能，它的做用是爲數據鏈路層提供接收方的幀地址
  • RARP協議
    • 反向地址轉換協議（RARP：Reverse Address Resolution Protocol）RARP容許局域網的物理機器從網關服務器的 ARP 表或者緩存上請求其 IP 地址。網絡管理員在局域網網關路由器裏建立一個表以映射物理地址（MAC）和與其對應的 IP 地址。當設置一臺新的機器時，其 RARP 客戶機程序須要向路由器上的 RARP 服務器請求相應的 IP 地址。假設在路由表中已經設置了一個記錄，RARP 服務器將會返回 IP 地址給機器，此機器就會存儲起來以便往後使用。

• 注：另外一個版本的ARP協議概述

  • 因爲在實際網絡的鏈路上傳送數據幀時，最終必須使用MAC地址。
  • ARP協議：完成主機或路由器的IP地址到MAC地址的映射，即解決嚇一跳走哪的問題。
  • ARP協議的使用過程：
    • 檢查ARP高速緩存，有對應表項則寫入MAC幀，沒有則用目的MAC地址爲FF-FF-FF-FF-FF-FF（全1）的幀封裝並廣播ARP請求分組，同一局域網中全部主機都能收到該請求。目的主機收到請求後就會向源主機單播一個ARP相應分組，源主機收到後將此映射寫入ARP緩存（10-20min更新一次）
  • ARP協議的4中典型狀況：
    • 主機A發給本網絡上的主機B：用ARP找到主機B的硬件地址；
    • 主機A發給另外一網絡上的主機B：用ARP找到本網絡上一個路由器（網關）的硬件地址；
    • 路由器發給本網絡的主機A：用ARP找到主機A的硬件地址；
    • 路由器發給另外一網絡的主機B：用ARP找到本網絡上的一個路由器的硬件地址。

• 瀏覽器中輸入一個URL後，按下回車後發生了什麼

  • 瀏覽器輸入域名發生了什麼？（Web頁面請求過程）
    • DNS域名解析獲得IP地址；瀏覽器與服務器簡歷TCP鏈接；發送HTTP請求報文；服務器響應；收到響應，html代碼；（釋放鏈接）；渲染頁面；
  • 瀏覽器會從主機的Hosts文件中查看是否有該域名和IP地址的映射；
  • 若是Hosts文件沒有，瀏覽器會查看本身的緩存；
  • 當上面兩個方法都行不通時，只能去請求DNS服務器來獲取IP地址；
  • 獲取到IP地址後，創建TCP鏈接、三次握手；
  • 確認鏈接後發送一個HTTP請求報文；
  • 服務器處理請求，並對請求作出響應；
  • 瀏覽器收到服務器響應，獲得html代碼；
  • 渲染頁面。（瀏覽器根據響應報文來解析CSS樣式、JS交互等等）

• APP連接點進後加載一段時間後仍無內容，分析可能的狀況

  • 網絡信號差
  • DNS解析慢
  • 創建連接慢
    • 當咱們獲取到服務器IP後，客戶端和服務器創建鏈接，這個連接的速度與質量取決於線路的優劣。最多見的問題就是跨線路訪問，地理位置相差很遠的訪問，中繼網絡異常等。排查方法：若是ping一個網址，存在大量丟包或者很高延遲（國內ping延遲超過50ms），就會致使訪問的鏈接線路異常。
  • 服務器響應慢
    • 當一個服務器健康運行，這個時間幾乎可忽略，可是若是服務器不那麼健康，好比CPU，內存，磁盤，帶寬，只要一個達到瓶頸的服務器就是亞健康，將直接影響訪問速度。排查方法：若是此前訪問很快的網站訪問忽然變慢了，在網絡無問題的狀況下，雲主機可查看內部資源使用狀況；虛擬主機則可經過執行簡單命令或直接訪問圖片來判斷服務器資源佔用狀況。
  • 自己問題，加載速度慢
    • 加載時間慢能夠說是最明顯、最大程度影響訪問速度的因素了。當用戶訪問一個網站時候，服務器會向客戶端發送大量的內容，這會佔用大量的服務器帶寬。帶寬就是最多見也是最直接影響打開的因素。

• DNS域名解析

• HTTPS抓包原理與charles抓包

  • 相比HTTP的明文傳輸，HTTPS進行了加密
  • 非對稱加密算法（公鑰和私鑰）交換對稱密鑰+數字證書驗證身份（驗證公鑰是不是僞造的）+利用對稱密鑰加解密後續傳輸的數據=安全
    
    

END