天天看點
傳回

計算機網絡 - 面試準備計算機網絡

計算機網絡

OSI 七層模型

計算機網絡 - 面試準備計算機網絡

實體層

資料以比特流的形式在實體層傳輸

裝置有中繼器、集線器（作用：轉發、放大信号）

資料鍊路層

負責将資料組幀，實作鍊路管理、流量控制和差錯控制

協定有GBN後退N幀協定、SR選擇重傳協定、以太網協定

裝置有網橋、交換機（作用：根據MAC位址對幀進行過濾轉發，可以隔絕沖突域，不能隔絕廣播域）

沖突域：同一時間内隻能有一台裝置發送資訊的範圍

廣播域：網絡中能接收到任意裝置發出的廣播幀的裝置的集合

網絡層

提供主機和主機之間的邏輯通信

協定有ARP協定、OSPF/RIP路由尋址協定、DHCP協定、ICMP協定、IGMP多點傳播協定、IP協定、CIDR協定

裝置有路由器（作用：轉發分組）

傳輸層

提供端到端的可靠封包傳遞，負責将資料傳送至對應端口，提供程序和程序之間的邏輯通信

協定有TCP UDP協定

會話層

負責建立、管理、終止程序之間的會話

表示層

對上層資料或者資訊進行變換，以保證一個主機應用層資訊可以被另一個主機應用層所了解，包括資料加密、格式轉換、壓縮等

應用層

為作業系統或者網絡應用程式提供通路網絡的接口 協定有HTTP FTP SMTP DNS協定

TCP/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上保留位址用于内部）
  • ipv6：128bit，16進制

http常見狀态碼

  • 1xx 通知
    • 100 continue 表示出的請求已經被伺服器接收，遊覽器應當繼續發送請求的其餘部分（HTTP1.1）（http封包中如果有post方法的話 會先把請求行發送過去，然後傳回100，然後再發送請求頭部和請求體給伺服器端）
    • 101 switching pototcols 伺服器将遵從客戶的請求轉換到另外一種協定（HTTP1.1）。
  • 2xx 成功
    • 200 OK 一切正常傳回資料
    • 201 created 伺服器已經建立了文檔，location 頭給出了他的URL。
    • 202 accepted 已經接收請求，但是尚未處理完成。
    • 203 non-authoritative information 文檔已經正常的傳回，但一些應答頭可能不正确，因為使用的是的文檔的拷貝(HTTP 1.1新)。
    • 204 No content 請求正常處理，但是沒有資料傳回
    • 206 指定範圍傳回（http1.1以上支援的斷點續傳功能相關）
  • 3xx 重定向
    • 301 永久性重定向：再也不用了
    • 302 Found 類似301，但新的URL應該被視為臨時性的替代，而不是永久性的，注意，在HTTP1.0中對應的狀态資訊moved Temporatily。出現該狀态碼，浏覽器能夠給自動通路新的URL，是以他是一個很有用的狀态代碼。
    • 303 暫時性重定向 但是伺服器端明确說明希望浏覽器用get方法來請求資源
    • 304 浏覽器附帶了請求的條件，伺服器端允許通路，但是不滿足請求條件
  • 4xx 用戶端錯誤
    • 400 用戶端的請求有文法錯誤
    • 401 unauthorized 客戶試圖未經授權通路受密碼保護的頁面。應答中會包含-WWW-Authenticate頭，浏覽器據此顯示使用者名字和密碼對話框，然後再填寫合适的authorization頭後再次發送請求。
    • 403 Forbidden 資源不可用。伺服器了解客戶的需求，但是拒絕處理他通常由于伺服器上檔案或目錄的權限設定問題。
    • 404 Not found 用戶端申請通路的資源不存在
    • 405 Method not allowed 用戶端請求方法被禁止
  • 5XX 服務端錯誤
    • 500 internal Server Error 伺服器遇到了意料不到的情況，不能完成客戶的請求
    • 501 Not lmplemented 伺服器不支援請求所需要的功能。例如，客戶發出來了一個伺服器不支援的put請求。
    • 502Bad Gateway 伺服器作為網關或者代理時，為了完成請求通路下一個伺服器，但該伺服器傳回了非法的應答。
    • 503 service unavilable 伺服器由于維護或者負載過重未能應答。例如，servlet 可能在資料庫連接配接池已滿的情況下傳回503.伺服器傳回503時可以提供一個retry-after頭。
    • 504 gateway timeout 作為代理或網關伺服器使用，表示不能及時的從遠端伺服器獲得應答（HTTP 1.1新）
    • 505 HTTPversion not supported 伺服器不支援請求中所指明的HTTP版本。（HTTP 1.1新）

常見應用端口

計算機網絡 - 面試準備計算機網絡
  • DNS：53
  • Shell/cmd:514
  • Apache:8080
  • Flask預設:5000

http,https,socket

  • HTTP全稱是HyperText Transfer Protocal，即：超文本傳輸協定，HTTP連接配接最顯著的特點是用戶端發送的每次請求都需要伺服器回送響應，在請求結束後，會主動釋放連接配接。從建立連接配接到關閉連接配接的過程稱為“一次連接配接”。
    • GET：對伺服器資源的簡單請求
    • POST：用于發送包含使用者送出資料的請求
      • GET請求的資料會附在URL後面，POST的資料放在HTTP包體
      • POST安全性比GET安全性高
    • HEAD：類似于GET請求，不過傳回的響應中沒有具體内容，用于擷取報頭
    • PUT：傳說中請求文檔的一個版本
    • DELETE：發出一個删除指定文檔的請求
    • TRACE：發送一個請求副本，以跟蹤其處理程序
    • OPTIONS：傳回所有可用的方法，檢查伺服器支援哪些方法
    • CONNECT：用于ssl隧道的基于代理的請求
  • HTTPS是HTTP over SSL/TLS，HTTP是應用層協定，TCP是傳輸層協定，在應用層和傳輸層之間，增加了一個安全套接層SSL/TLS：
    • SSL (Secure Socket Layer，安全套接字層)
    • TLS (Transport Layer Security，傳輸層安全協定)
    • SSL使用40 位關鍵字作為RC4流加密算法（對稱加密算法）
  • socket隻是一種連接配接模式，不是協定，socket是對TCP/IP協定的封裝，Socket本身并不是協定，而是一個調用接口（API），通過Socket，我們才能使用TCP/IP協定。tcp、udp，簡單的說（雖然不準确）是兩個最基本的協定，很多其它協定都是基于這兩個協定如，http就是基于tcp的，用socket可以建立tcp連接配接，也可以建立udp連接配接，這意味着，用socket可以建立任何協定的連接配接，因為其它協定都是基于此的。
  • 如何标記http：socket四元組

GET和POST

  • 注意存放在請求行和請求體的不是方法 而是請求/送出的資料， post和get方法都是在請求行中啦
  1. get資料明文存放在http請求行的url之後，post則是将送出的資料放在http請求封包的請求體中
  2. 受浏覽器對url長度的限制，get傳送資料量應不超過2KB。post傳送資料量則一般無此限制
  3. get隻接受acsii字元，post沒有限制，get隻支援url編碼，post沒有限制
  4. get不能改變伺服器的資料，一般用于從伺服器擷取資料，是幂等的；post可以改變伺服器的資料，不是幂等的。（從定義上看，HTTP方法的幂等性是指一次和多次請求某一個資源應該具有同樣的副作用）
  5. get請求可以被浏覽器主動緩存，下一次若傳輸資料相同，則優先傳回緩存中的内容，以加快顯示速度。post請求不會，除非手動設定一下
  6. get請求參數會被完整地儲存在浏覽器曆史記錄中，post請求參數則不會保留

cookie和session

  • session可以和cookie是同一層的實體概念，也可以指抽象的一對一的身份認證功能的抽象描述。從抽象的session來看，cookie可以算是抽象session的一種實作。當然，我們主要讨論的是兩種實體之間的聯系。
  • 首先它們都是用于給無連接配接的http提供身份認證的功能
  • cookie是伺服器在本機存放的小段文本，并随每一個請求發送至同一伺服器。cookie分為會話cookie（不設定過期時間，關閉浏覽器視窗cookie即失效，儲存在記憶體中）和持久cookie（設定過期時間，關閉再打開浏覽器cookie仍存在，直至達到過期時間）。類似于檢查通行證（即請求封包中附帶的cookie）來确定使用者身份
  • session則一般是利用session id實作的（session id是浏覽器第一次發送請求時伺服器自動生成的唯一辨別，并傳回給浏覽器），cookie中攜帶該session id，用戶端根據該session id将session檢索出來。類似于在伺服器上建立一個客戶檔案，客戶來訪時需要查詢客戶檔案
  • cookie是存放在用戶端，用于記錄使用者資訊的，比如自動填充使用者名和密碼；session是存放在伺服器端的，用于記錄使用者的狀态，比如購物車的實作。
  • cookie不太安全，可以分析存放在本地的cookie進行cookie欺騙，（也可以用加密算法加密後進行存放），session存放于伺服器的記憶體中，是以安全性高
  • 單個cookie儲存資料不能超過4k，session沒有對存儲資料量的限制
  • 禁掉cookie的話session仍然可以使用，但是需要使用其他方法擷取session id，比如在url後面或者以表單的形式送出給伺服器端

IP與MAC ：他們能互相替代嗎

  • MAC位址是網絡中每個裝置都有的唯一網絡辨別，全世界唯一。
  • IP位址隻是邏輯上的辨別，任何人都能随意修改，是以不能具體辨別一個使用者，但MAC位址固化在網卡裡，防止被盜用。
  • 但是如果隻用MAC位址的話，因為MAC位址無序雜亂，沒有明顯規則，難以查找。但是IP是分層的，類似通訊位址，可以根據其網絡号找到子網再定義主機，逐級查找，每個裝置需要存儲的資訊較少

  • MAC位址與IP位址的差別：

    ①長度不同，IP位址一般為32位（IPv6 128位），MAC位址則是48位

    ②配置設定依據不同，IP位址配置設定基于網絡拓撲，能夠根據需要改動裝置的IP位址，但是MAC位址的配置設定是基于制造商，在網卡中燒錄好，一般不輕易改變

    ③尋址協定層不同，IP位址應用于網絡層，MAC位址應用于資料鍊路層（資料鍊路層基于MAC位址轉發資料幀，資料鍊路層的交換機根據其MAC位址記錄表中的MAC位址及其對應的端口，将其發送到MAC位址對應的端口，否則廣播；網絡層則根據IP位址轉發封包，路由器根據路由表轉發到對應端口，否則發送預設路由）

ARP

  • 作用：實作IP位址到MAC位址的映射（由IP位址獲得MAC位址）
  • 流程：根據主機A路由表的内容查找B的IP位址，再從A的ARP高速緩存中尋找是否有B的MAC位址，如果沒有則廣播ARP請求幀（構成為Aip+Bip+A_MAC+全1）至該區域網路内所有的主機。如果主機發現該請求幀中的IP位址與自己的相同則傳回一個單點傳播ARP幀（構成為Bip+B_MAC)傳回給主機A，并且AB均更新自己的ARP高速緩存。

DNS：域名與IP / DNS劫持

  • 當DNS客戶機需要在程式中使用名稱時，它會查詢DNS伺服器來解析該名稱。客戶機發送的每條查詢資訊包括三條資訊：包括：指定的DNS域名，指定的查詢類型，DNS域名的指定類别。
  • 基于UDP服務，端口53. 該應用一般不直接為使用者使用，而是為其他應用服務，如HTTP，SMTP等在其中需要完成主機名到IP位址的轉換。
  • DNS劫持也可以了解為使用者的請求去往了錯誤的DNS伺服器進行查詢解析，傳回來的目的主機IP自然不是我們想要達到的資源伺服器主機。當然，如果DNS伺服器有意将解析位址引到其他緩存，或者為了廣告收益将解析位址指向廣告網站，這也可能是劫持的原因。

NAT：内外網

  • NAT路由器上将其本地位址轉換成全球IP位址

浏覽器請求網頁全過程 / http全流程

計算機網絡 - 面試準備計算機網絡
  • 對網址進行DNS域名解析，得到對應的IP位址
  • 根據這個IP，找到對應的伺服器，發起TCP的三次握手
  • 建立TCP連接配接後發起HTTP請求
  • 伺服器響應HTTP請求，浏覽器得到html代碼
  • 浏覽器解析html代碼，并請求html代碼中的資源（如js、css、圖檔等）（先得到html代碼，才能去找這些資源）
  • 浏覽器對頁面進行渲染呈現給使用者
  • 伺服器關閉關閉TCP連接配接或者保持連接配接keep-alive
  • 注：
    • DNS怎麼找到域名的？
      • DNS域名解析采用的是遞歸查詢的方式，過程是，先去找DNS緩存->緩存找不到就去找根域名伺服器->根域名又會去找下一級，這樣遞歸查找之後，找到了，給我們的web浏覽器
    • 為什麼HTTP協定要基于TCP來實作？
      • TCP是一個端到端的可靠的面相連接配接的協定，HTTP基于傳輸層TCP協定不用擔心資料傳輸的各種問題（當發生錯誤時，會重傳）
    • 最後一步浏覽器是如何對頁面進行渲染的？
      • 解析html檔案構成 DOM樹
      • 解析CSS檔案構成渲染樹
      • 邊解析，邊渲染
      • JS 單線程運作，JS有可能修改DOM結構，意味着JS執行完成前，後續所有資源的下載下傳是沒有必要的，是以JS是單線程，會阻塞後續資源下載下傳

TCP/UDP

  • TCP是一種可靠的、面向連接配接的位元組流服務。源主機在傳送資料前需要先和目标主機建立連接配接。然後，在此連接配接上，被編号的資料段按序收發。同時，要求對每個資料段進行确認，保證了可靠性。如果在指定的時間内沒有收到目标主機對所發資料段的确認，源主機将再次發送該資料段。
  • UDP：UDP是一種不可靠的、無連接配接的資料報服務。源主機在傳送資料前不需要和目标主機建立連接配接。資料被冠以源、目标端口号等UDP報頭字段後直接發往目的主機。這時，每個資料段的可靠性依靠上層協定來保證。在傳送資料較少、較小的情況下，UDP比TCP更加高效。（面向字元流，不限長度，以包的形式傳輸，沒有擁塞控制）
  • 封包段
    計算機網絡 - 面試準備計算機網絡
    計算機網絡 - 面試準備計算機網絡
  • IP資料報格式
    計算機網絡 - 面試準備計算機網絡

TCP三向交握

  • 原因：確定雙方間的連接配接正常建立，如果隻有兩次握手的話可能會出現一些異常情況，比如：
    • ①用戶端的SYN連接配接請求失效(或者發去時間太久,導緻了逾時重傳的發生)，但是伺服器端接收到了該SYN封包，如果不經過第三次握手的話伺服器端就會錯誤地開啟一個連接配接；
    • ②如果隻有兩次握手地話，伺服器端傳回給用戶端的确認封包丢失，會導緻用戶端因為沒有收到确認是以關閉了該連接配接，但伺服器端此時已做好了連接配接準備，造成資源的浪費
  • 第一次握手：用戶端發送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 連接配接都将被一直保持下去。

TCP SYN攻擊

  • 攻擊者僞裝成用戶端發送TCP的SYN封包, 當伺服器傳回ACK确認封包之後, 攻擊者不再進行确認, 即不回複确認的确認封包, 這個連接配接就處于一個挂起的狀态, 伺服器收不到确認封包的話, 會啟用逾時重傳機制, 重複發送ACK給攻擊者
  • 這樣的話,如果攻擊者開啟大量這種TCP連接配接, 導緻伺服器端有很多個挂起的連接配接, 并且需要重複發送很多ACK給攻擊者, 這樣就會消耗伺服器的記憶體 可能導緻最後伺服器當機, 無法正常工作
  • 解決方法：
    • 降低SYN timeout時間 使得伺服器在沒收到确認封包後盡快釋放半連接配接的占用
    • 采用SYN cookie設定 給每一個請求連接配接的ip位址配置設定一個cookie,短時間内如果連續收到某個IP的重複的SYN封包,就認定收到了攻擊,以後會自動丢棄該ip位址傳送過來的包

TCP四次握手

  • 與建立連接配接的“三次握手”類似，斷開一個TCP連接配接則需要“四次握手”。原因：
    • 因為建立連接配接時雙方都處于closed狀态，而釋放連接配接時一方收到FIN封包但有可能還有資料要繼續傳輸，不能馬上釋放連接配接，是以先傳回一個确認封包，發送完資料後再斷開連接配接
  • 第一次揮手：主動關閉方發送一個FIN，用來關閉主動方到被動關閉方的資料傳送，也就是主動關閉方告訴被動關閉方：我已經不 會再給你發資料了(當然，在fin包之前發送出去的資料，如果沒有收到對應的ack确認封包，主動關閉方依然會重發這些資料)，但是，此時主動關閉方還可 以接受資料。（半關閉狀态）
  • 第二次揮手：被動關閉方收到FIN包後，發送一個ACK給對方，确認序号為收到序号+1（與SYN相同，一個FIN占用一個序号）。
  • 第三次揮手：被動關閉方發送一個FIN，用來關閉被動關閉方到主動關閉方的資料傳送，也就是告訴主動關閉方，我的資料也發送完了，不會再給你發資料了。
  • 第四次揮手：主動關閉方收到FIN後，發送一個ACK給被動關閉方，确認序号為收到序号+1，至此，完成四次揮手。
  • 請求關閉方在TIME-WAIT狀态等待2MSL的原因 ：确認伺服器端是否正常收到了用戶端最後發出的确認封包，如果伺服器端沒有收到的話，過1MSL（封包在網絡中的最大存活時間）會重新再發送一次FIN封包給用戶端，如果過了2MSL還沒有收到新發的FIN封包的話，證明伺服器端已經收到确認封包并正常關閉連接配接，用戶端也可以關閉連接配接啦~

TCP可靠性保證

  1. 分段 将封包段分成适合轉發的長度
  2. 标号 按照序号判斷中間的轉發是否有缺失
  3. 流量控制 根據雙方的接收發送能力，動态地調整發送方發送視窗的大小，取發送視窗=min(擁塞視窗，接收視窗) （與資料鍊路層收不下的話傳回一個信号告訴發送方自己收不下的流量控制機制不同）
  4. 檢驗和 TCP首部有檢驗和字段，目的是檢驗首部+資料部分的資料是否正确，是不是被人篡改或半路出現差錯。
  5. 逾時重傳 發出封包段之後啟動定時器，如果重傳時間RTT内沒有收到确認的話，就重傳該資料報，也可以采用備援确認機制（三次接收到同一個ack=k的确認序号，就重傳第k個封包段）（快重傳中采用的也是備援重傳）。主要涉及的協定有兩種（跟資料鍊路層的逾時重傳機制相同）：
    • 停止等待協定 每發送一個封包段就停止，直到收到确認才繼續發送，否則逾時重傳
    • 滑動視窗協定：
      • 後退N幀協定 GBN： 發送視窗>1，接收視窗=1，即接收方必須按照順序去接收資料，如果啟用了逾時重傳機制的話，就會重傳所有目前已經發送但是沒有被确認的封包段
      • 選擇重傳協定 SR： 發送視窗>1，接收視窗>1，即接收方無需按照順序去接收資料，會按照任意順序接收所有處于接收視窗内的資料。按照如果啟用逾時重傳機制的話隻需要重新發送沒有收到确認的資料即可。
  6. 擁塞避免 分為兩種：①慢開始，擁塞避免 ②快重傳、快恢複

擁塞控制

計算機網絡 - 面試準備計算機網絡
  • 慢開始/擁塞避免/快重傳/快恢複
    • 當cwnd<ssthresh時，使用慢開始算法。
    • 當cwnd>ssthresh時，改用擁塞避免算法。
    • 當cwnd=ssthresh時，慢開始與擁塞避免算法任意
  • 慢開始：cwnd以位元組為機關
    • cwnd=cwnd*2
    • 當cwnd>ssthresh時，改用擁塞避免算法。
  • 擁塞避免：
    • cwnd=cwnd+1
  • 逾時：
    • ssthresh=cwnd/2
    • cwnd=1
  • 接收方連續傳給發送方三個ACK（丢失封包）：
    • 快重傳/快恢複
    • ssthresh=cwnd/2
    • cwnd=ssthresh
    • 也就是說開始擁塞避免
面試準備 網絡 http
上一篇: python 調用支付寶微信接口_前端在h5頁面調起微信支付接口和支付寶接口（日常筆記）...
下一篇: Python支付接口彙總大全（包含微信、支付寶等）

繼續閱讀