網絡常見問題合集

面筋分類匯總-測開向

• 7層/5層/4層網絡

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

• OSI分層 （7層）：

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

• TCP/IP分層（4層）：

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

• 五層協議 （5層）：

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

• 每一層的協議如下

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

• 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支持一對一、一對多、多對一和多對多的交互通信。
    • 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的可靠性傳輸。
    • 1、添加seq/ack機制，確保數據發送到對端
    • 2、添加發送和接收緩沖區，主要是用戶超時重傳。
    • 3、添加超時重傳機制。

• 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的區別

    • 1、Cookie和Session都是會話技術，Cookie是運行在客戶端，Session是運行在服務器端。
    • 2、Cookie有大小限制以及瀏覽器在存cookie的個數也有限制，Session是沒有大小限制
      • 單個cookie保存的數據不能超過4K，很多瀏覽器都限制一個站點最多保存20個cookie。
      • session是沒有大小限制，和服務器的內存大小有關。
    • 3、Cookie有安全隱患，通過攔截或本地文件找得到你的cookie后可以進行攻擊。
      • 別人可以分析存放在本地的cookie並進行cookie欺騙
      • 考慮到安全應當使用session。
    • 4、Session是保存在服務器端上會存在一段時間才會消失，如果session過多會增加服務器的壓力。
      • 考慮到減輕服務器性能壓力方面，應當使用cookie。
    • 5、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