每日一句：想得到世上最好的東西，先得讓世界看到最好的你
目錄
面試問OSI或TCP/IP,怎么回答？
面試問HTTP？
面試問Get類型，Pot類型區別？
面試什么是Socket套接字？
面試問什么是數據粘包？
粘包產生原因？
面試問什么是數據分包？
分包產生的原因就簡單的多：
粘包與分包的處理方法：
為什么UDP沒有粘包?
一組數據包的聲明周期過程？
心跳包
客戶端發“hello”經過OSI每一層都加一個協議頭，封裝成報，通過連接到互聯網，物理層發送到服務端，接到后，再把一層層頭去掉，得到“hello”
面試問OSI或TCP/IP,怎么回答？
- 網絡的傳輸層次結構
- OSI——>簡化TCP/IP模型，把應用，表示，會話——>合成應用層
- 每層經典數據協議
HTTP協議請求時，有請求頭，響應頭
客戶端首先發一個請求協議，發送到服務端回一個響應協議
*TCP短鏈接
在每次傳輸時都會建立一個通訊信道，傳輸后關閉連接。關閉后服務器就找不到客戶端了，需要待下一個客戶端發起連接時才能找到
TCP長連接
客戶端和服務端一開始會連接，并一直保持，直到不再交換數據斷開。
UDP無連接，直接數據報投給你
區別：
- 長連接一直連接，服務器可隨時向客戶端發數據，短連接不可以
- 短鏈接性能消耗大
帶寬計算 運營商 比特 ?個體 字節
通訊協議
IP協議 用于網絡定位的一個數據串
TCP協議
- 服務器開始接收
- 客戶端發送連接請求
- 如果達到服務端，服務端給相應
面試問HTTP？
是超文本傳輸協議，位于應用層，基于TCP協議開發。特點是傳輸時，有數據完整性校驗（校驗數據在頭部信息中）
面試問HTTPS?
加密后的HTTP協議
- 敏感數據傳參，加密數據更安全
- 防釣魚網站
HTTP協議構成
URL結構
通訊協議：：Http:// ?Https://
主機地址：IP，域名
端口號：80端口提供Http服務，443端口提供Https服務
目錄：“/目錄名”
腳本名稱
URL參數
“?參數名=參數值&參數名=參數值”
?URL地址可以進行偽裝
HTTP狀態號
200成功
301重定向（當前網頁已過時，跳轉到新頁面）
403當前目錄禁止訪問
404網頁不存在
500服務器內部錯誤
502訪問量過大，不能提供服務
HTTP請求類型
Get類型 僅作網頁請求連接
Post類型 用戶名登錄時，要作表單數據類型發送
面試問Get類型，Pot類型區別？
- Get類型通過URL地址傳遞的;Post類型數據通過HTTP數據頭傳遞的
- Get類型會被記錄下來，Post類型相對安全
- Get類型傳遞數據長度受URL限制；Post可以傳遞任意長度數
如果需要在URL傳遞數據中加入特殊字符，需要對數據進行URL編碼
TCP長連接
面試什么是Socket套接字？
套接字是將IP地址與主機端口號合并在一起后的數據，IP地址定位主機位置，端口號知道通訊入口與出口，從而實現主機的數據交換
Socket基于傳輸層實現
TCP編程方式（c#）
連接（三次握手）——>斷開（四次揮手）——>監聽，綁定（服務器開發）——>接收——>發送
發送數據含頭部信息，網卡里有緩存，累積之后再發怎么處理
數據包處理
面試問什么是數據粘包？
TCP協議中，發送方發送的若干包數據到接收方接收時粘成一包，從接收緩沖區看，后一包數據的頭緊接著前一包數據的尾。
發送數據前，如果有多個數據包要一起發送，則可以將數據包拼在一起發送，這樣效率更高
粘包產生原因？
先說TCP：由于TCP協議本身的機制（面向連接可靠的協議，三次握手四次揮手）客戶段與服務端會建立一個鏈接，數據在鏈接不斷開的情況下，可以持續不斷地將多個數據包發往服務端，相當于一個流，但是如果發送的網絡數據包太小，那么他本身會啟用Nagle算法（當然是可配置是否啟用）對較小的數據包進行合并（基于此，TCP的網絡延遲要UDP的高些，因為需要合并延時發送）然后再發送（超時或者包大小足夠）。這樣的話，服務端在接收到消息（數據流）的時候就無法區分哪些數據包是客戶端自己分開發送的，這樣產生了粘包；還有一種情況，服務端在接收到數據后，然后放到緩沖區中，如果消息沒有被及時從緩存區取走，下次在取數據的時候可能就會出現一次取出多個數據包的情況，造成粘包現象（確切來講，對于基于TCP協議的應用，不應用包來描述，而應該用流的概念來描述）
面試問什么是數據分包？
當接到數據后，需要將每一個定制的數據格式分離出來，所寫的代碼就是分包代碼，有時服務器是硬件將拼接在一起，有時是代碼將數據包拼接在一起，拼接后的代碼，效率更高
分包產生的原因就簡單的多：
可能是IP分片傳輸導致的，也可能是傳輸過程中丟失部分包導致出現的半包，還有可能就是一個包可能被分成了兩次傳輸，在取數據的時候，先取到了一部分（還可能與接收的緩沖區大小有關系），總之就是一個數據包被分成了多次接收。
粘包與分包的處理方法：
一個是采用分隔符的方式，即我們在封裝要發送的數據包的時候，采用固定的字符作為結尾符（數據中不能含結尾符），這樣我們接收到數據包后，如果出現結尾標識，即人為的將粘包分開，如果一個包中沒有出現結尾符，認為出現了分包，則等待下個包中出現后 組合成一個完整的數據包，這種方式適合于文本傳輸的數據，如采用/r/n之類的分隔符；
另一種是采用在數據包中添加長度的方式，即在數據包中的固定位置封裝數據包的長度信息（或可計算數據包總長度的信息），服務器接收到數據后，先是解析包長度，然后根據包長度截取數據包（此種方式常出現于自定義協議中），但是有個小問題就是如果客戶端第一個數據包數據長度封裝的有錯誤，那么很可能就會導致后面接收到的所有數據包都解析出錯（由于TCP建立連接后流式傳輸機制），只有客戶端關閉連接后重新打開才可以消除此問題，我在處理這個問題的時候對數據長度做了校驗，會適時的對接收到的有問題的包進行人為的丟棄處理（客戶端有自動重發機制，故而在應用層不會導致數據的不完整性）；
為什么UDP沒有粘包?
粘包拆包問題在數據鏈路層、網絡層以及傳輸層都有可能發生。日常的網絡應用開發大都在傳輸層進行，由于UDP有消息保護邊界，不會發生粘包拆包問題，因此粘包拆包問題只發生在TCP協議中。
打包
對原始數據添加協議頭的過程
解包
接收到數據包時，讀取包頭，并記錄信息，獲取到包內原始數據的過程
一組數據包的聲明周期過程？
- 對原始數據打包
- 對多個數據包粘包
- 套接字（連接，發送）
- 套接字（接收）
- 有可能同時接收到多個數據黏在一起，對數據進行（分包）
- 取得單個數據的原始數據（解包）
- 根據數據包，執行代碼邏輯
數據包定制
包頭：記錄有關于整個數據包的信息（可加密）
包體：原始數據（可加密）
字節序（存在于數字存儲方法）
小端字節序：將數據的后位字節，放在內存棧的低地址位
大端字節序：將數據的后位字節，放在內存棧的高地址位
主機字節序：當前計算機數字的字節表示方式
網絡字節序：互聯網規定，傳遞數據時，都轉大端字節序
字符串內有字節序問題，它受字符編碼影響
心跳包
因為TCP是有連接的，所以必須在兩個PC間建立連接，但是如果長時間連接卻又不發送數據，則會占用互聯網的通信信道，就有可能被網絡的中間設備（路由器，防火墻）將網絡連接斷開，所以防止網絡被斷開，則需要兩臺計算機間定期發送一些數據，這樣的數據就是心跳數據
網絡延遲計算：服務器返回心跳時間-客戶端發送心跳時間
)
