計算機網絡-校招總結

計算機網絡的重要性不言而喻, 也是計算機基礎裏面關鍵的一環與面試熱點, 以前收集了一些問題和知識點, 如今此分享

針對目標

• 學完書本知識就忘記的我
• 本科網絡工程可是對網絡所知甚少的我
• 只偏向於工程應用而不熱衷理論研究的我
• 不想在校招中裸奔的我

• 偶爾路過的你

  內容

  計算機網絡中熱點面試問題, 我認爲應該知道的一些基礎知識; 不會深究太多, 以我認爲夠用爲界

  網絡分層

  七層參考模型

  具體展開再也不深刻
• 應用層
• 表示層
• 會話層
• 傳輸層
• 網絡層
• 鏈路層

• 物理層

TCP ip模型

應用層

注意事項:
在OSI模型中ARP協議屬於鏈路層；而在TCP/IP模型中，ARP協議屬於網絡層。

Tcp ip中的數據流

應用層
    定義數據格式，並按照對應的格式解讀數據
    應用層定義了各類各樣的協議來規範數據格式
        HTTP
        FTP
    好比http報文的頭部格式
傳輸層
    引入相關通訊協議
        定義端口
        爲了給每一個應用程序標識身份
        找到IP標定的主機上,具體接收數據的端口
    UDP數據包
    TCP數據包
網絡層
    IP地址
        確認主機所在的網絡位置，並經過IP進行MAC尋址
        對外網數據包進行路由轉發
    在網絡層被包裝的數據包就叫IP數據包
    網絡層的主要工做是定義網絡地址，區分網段，子網內MAC尋址，對於不一樣子網的數據包進行路由
鏈路層
    MAC地址
        鏈路層定義了主機的身份，即MAC地址
        定義數據幀，確認主機的物理地址，傳輸數據；
    在鏈路層生成以太網數據包
    以太網數據包經過物理介質傳輸給對方主機

TCP協議

一些基本問題

TCP與UDP的區別
    TCP面向鏈接
    可靠的流協議
        順序控制
        流量控制
        擁塞控制
    UDP
        有更高的實時性
        不可靠的數據報協議
        不能保證必定會送達

爲何要三次握手?
    三次握手的目的是創建可靠的通訊信道
    雙方確認本身與對方的發送與接收是正常的

三次握手的過程

    客戶端發送syn包(seq=x)到服務器
        客戶端SYN_SEND狀態，等待服務器確認
    服務器收到syn包，必須確認客戶的SYN(ack=x+1)，同時本身也發送一個SYN包(seq=y)，即SYN+ACK包
        服務器進入SYN_RECV狀態
    客戶端收到服務器的SYN+ACK包，向服務器發送確認包ACK(ack=y+1)，
        此包發送完畢，客戶端和服務器進入ESTABLISHED狀態，完成三次握手

TCP四次握手

        客戶端或服務器都可主動發起揮手動做，在socket編程中，任何一方執行close()操做便可產生揮手操做

        1.主動方申請關閉鏈接,發送FIN報文,意味着這一方沒有要發送的數據了!
                狀態變爲FIN-WAIT-1
        2.被動方接收,發送ACK,先發送一個確認, ACK和ack
            這時候尚未真正的發送完被動方的數據
            狀態變爲CLOSE_wait
        3.主動方狀態變爲FIN-wait2
            被動方發送FIN, 意味着被動方也發送完了
            LAST-ack狀態
        4.主動方發送確認,正式要關閉鏈接
            主動方等待2MSL後,沒有回覆 關閉鏈接

TCP協議中的一些細節

tcp如何保證可靠性

使用以下技術

• 校驗和
• 序列號
• 確認應答
• 重發控制
• 鏈接管理
• 窗口管理

TCP怎麼保證鏈接的惟一性

• TCP/IP惟一性含除地址和端口外, 還有一個時間上的標記纔可徹底確立。
• 對TCP而言在三次握手時的SYN標誌會使用上一個ISN值
• 每一次鏈接都會分配到一個ISN值，鏈接雙方對這個值會記錄共識，假如這個值不一，就說明了這個鏈接已超時或無效

TCP窗口的做用

• 進行流量控制的
• tcp的應答不是對每一個段的
• 而是以一個更大的單位-窗口

tcp 粘包拆包問題是怎麼產生的？何時會發生? 怎麼來解決?

• tcp的協議數據不會丟，沒有收完包，下次接收，會繼續上次繼續接收，己端老是在收到ack時纔會清除緩衝區內容。數據是可靠的，可是會粘包和拆包問題。(UDP不會發生粘包)
• 兩種狀況下發生粘包: 發送端須要等緩衝區滿才發送出去，兩個數據包過小了,形成粘包; 客戶端發送了一段數據，服務端只收了一小部分，服務端下次再收的時候仍是從緩衝區拿上次遺留的數據，產生粘包.
• 兩種狀況下發生拆包:要發送的數據大於TCP發送緩衝區剩餘空間大小，將會發生拆包; 待發送數據大於MSS（最大報文長度），TCP在傳輸前將進行拆包
• 解決的關鍵: 接收端不知道發送端將要傳送的字節流的長度，因此解決粘包的方法就是圍繞: 如何讓接收端有辦法知道哪裏是終止.
• 方法1:發送端給每一個數據包添加包首部，首部中應該至少包含數據包的長度，這樣接收端在接收到數據後，經過讀取包首部的長度字段，便知道每個數據包的實際長度了。
• 方法2:發送端將每一個數據包封裝爲固定長度（不夠的能夠經過補0填充）
• 方法3:能夠在數據包之間設置邊界，如添加特殊符號，這樣，接收端經過這個邊界就能夠將不一樣的數據包拆分開

TCP的擁塞控制

思路
    爲防止傳輸的阻塞,經過一個慢啓動獲得的數值來控制發送的數據量
    發送方維持一個叫作擁塞窗口的狀態變量
    不要一開始就發送大量的數據，先探測一下網絡的擁塞程度，也就是說由小到大逐漸增長擁塞窗口的大小
    主要要記住的就是下面四個算法,
慢啓動階段
    意思是剛剛加入網絡的鏈接，一點一點地提速，不要一上來就把路佔滿。
    把擁塞窗口設爲1個數據段
    指數性增長,直到第一次丟失
擁塞避免
    到達一個閾值後,開始線性增長
快重傳
    快重傳要求接收方在收到一個失序的報文段後就當即發出重複確認
快恢復
    和快重傳算法配合使用，當發送方連續收到3個重複確認時就執行乘法減少算法，把慢開始門限ssthresh減半
    但因爲發送 方 連續 收到 幾個重傳確認，因此認爲此事網絡無阻塞，因此此時不執行慢開始算法，而是讓cwnd 從 ssthresh開始執行擁塞避免算法（加法增大）。

HTTP協議

什麼是http協議?
    是一個基於請求與響應模式的
    無狀態的
    基於TCP的鏈接方式
    應用層的協議

http請求方法
    經常使用的方法有哪些?
        get
        post
    get 和 post 請求有哪些區別？
        get的參數在url中
        post的經過request Body傳遞
        GET請求在URL中傳送的參數是有長度限制的
        get重點在從服務器上獲取資源

post重點在向服務器發送數據
        get是不安全的，由於URL是可見的，可能會泄露私密信息，如密碼等；

post較get安全性較高；

http請求報文和響應報文
    請求報文
        請求行
        請求首部字段
        請求實體
    響應
        狀態行
        響應首部字段
        響應實體

http協議2.0和1.1的區別
    HTTP/2是徹底多路複用的
    HTTP/2採用二進制格式而非文本格式
    HTTP/2讓服務器能夠將響應主動「推送」到客戶端緩存中
    header壓縮

https的原理，如何加密解密
    Https在真正請求數據前，先會與服務有幾回握手驗證，以證實相互的身份
    客戶端向服務器發起HTTPS請求，鏈接到服務器的443端口
    服務器將本身的公鑰發送給客戶端
    客戶端收到服務器端的公鑰以後，會對公鑰進行檢查，驗證其合法性
        驗證成功,生成隨機的對稱祕鑰
    客戶端會發起HTTPS中的第二個HTTP請求，將加密以後的客戶端密鑰發送給服務器
    服務器接收到客戶端發來的密文以後，會用本身的私鑰對其進行非對稱解密
        這樣兩邊就有了一對對稱祕鑰
    以後就能夠了

http經常使用狀態碼
    1xx：指示信息--表示請求已接收，繼續處理
    2xx：成功--表示請求已被成功接收、理解、接受
        200：請求被正常處理
        204：請求被受理但沒有資源能夠返回
    3xx：重定向--要完成請求必須進行更進一步的操做
        301：永久性重定向
        302：臨時重定向
    4xx：客戶端錯誤--請求有語法錯誤或請求沒法實現
        400：請求報文語法有誤，服務器沒法識別
        401：請求須要認證
        403：請求的對應資源禁止被訪問
        404：服務器沒法找到對應資源
    5xx：服務器端錯誤--服務器未能實現合法的請求
        500：服務器內部錯誤
        503：服務器正忙