1. 說說TCP的三次握手
傳輸控制協(xié)議TCP簡介
面向連接的、可靠的、基于字節(jié)流的傳輸層通信協(xié)議
將應(yīng)用層的數(shù)據(jù)流分割成報文段并發(fā)送給目標節(jié)點的TCP層
數(shù)據(jù)包都有序號，對方收到則發(fā)送ACK確認，未收到重傳
使用校驗和來檢驗數(shù)據(jù)在傳輸過程中是否有誤
TCP報文頭
TCP FLags
- URG: 緊急指針標志
- ACK: 確認序號標志
- PSH： push標志
- RST：重置鏈接標志
- SYN：同步序列號，用于建立連接過程
- FIN：finish標志，用于釋放連接
- 三次握手
三次握手
在TCP/IP協(xié)議中，TCP協(xié)議提供可靠的連接服務(wù)，采用三次握手建立一個連接。
- 第一次握手：建立連接時，客戶端發(fā)送SYN包（syn=j）到服務(wù)器，并進入SYN_SEND狀態(tài)，等待服務(wù)器確認；
- 第二次握手：服務(wù)器收到SYN包，必須確認客戶端的SYN（ack=j+1）,同時自己也發(fā)送一個SYN包（syn=k），即SYN+ACK包，此時服務(wù)器進入SYN_RECV狀態(tài)；
- 第三次握手：客戶端收到服務(wù)器的SYN+ACK包，向服務(wù)器發(fā)送確認包ACK（ack=k+1）,此包發(fā)送完畢，客戶端和服務(wù)器端進入ESTABLSHED狀態(tài)，完成三次握手。
- 為什么需要三次握手才能建立起連接
- 為了初始化Sequence Number的初始值
- TCP需要拼接各端的seq number
- 首次握手的隱患——SYN超時
- 問題起因分析
- Server收到Client的SYN，回復(fù)SYN-ACK的時候未收到ACK確認
- Server不斷重試至超時（5次，1+2+4+8+16+32秒），Linux默認等待63秒TCP才能斷開連接
- 針對SYN Flood的防護措施
- 服務(wù)器被惡意程序SYN發(fā)送報文占用，等待63秒期間進行攻擊
- SYN隊列滿后，通過tcp_syncookies參數(shù)回發(fā)SYN Cookie
- 若為正常連接則Client會回發(fā)SYN_Cookie，直接建立連接
建立連接后，Client出現(xiàn)故障怎么辦
-
?；顧C制
- 向?qū)Ψ桨l(fā)送?；钐綔y報文，如果未收到響應(yīng)則繼續(xù)發(fā)送
- 嘗試次數(shù)達到?；钐綔y數(shù)仍未收到響應(yīng)則中斷連接
2. 說說TCP的四次揮手
揮手是為了終止連接，TCP四次揮手的流程圖如下：
四次揮手
MSL最長報文時間：
TCP采用四次揮手來釋放連接
- 第一次揮手： Client發(fā)送一個FIN，用來關(guān)閉Client到Server的數(shù)據(jù)傳送，Client進入FIN_WAIT_1狀態(tài)；
- 第二次揮手： Server收到FIN后，發(fā)送一個ACK給Client，確認序列號為序號+1（與SYN相同，一個FIN占用一個序號），Server進入CLOSE_WAIT狀態(tài)；
- 第三次揮手： Server發(fā)送一個FIN，用來關(guān)閉Server到Client的數(shù)據(jù)傳送，Server進入LAST_ACK狀態(tài)；
- 第四次揮手： Client收到FIN后，Client進入TIME_WAIT狀態(tài)，接著發(fā)送一個ACK給Server，確認序號為收到序號+1，Server進入CLOSED狀態(tài)，完成四次揮手。
為什么會有TIME_WAIT狀態(tài)
- 原因：
- 確保有足夠的時間讓對方收到ACK包
- 避免新舊連接混淆
為什么需要四次揮手才能斷開連接
因為TCP是全雙工的，發(fā)送方和接收方都是需要FIN報文和ACK報文
服務(wù)器出現(xiàn)大量CLOSE_WAIT狀態(tài)的原因
客戶端關(guān)閉socket連接，服務(wù)端忙于讀或?qū)?，沒有及時關(guān)閉連接
檢查代碼，特別是注釋代碼
檢查配置，特別是處理請求的線程配置
查看服務(wù)器連接情況
netstat -n | awk '/^tcp/{++S[$NF]}END{for(a in S) print a,S[a]}'
3. TCP 滑動窗口
RTT和RTO
- RTT：發(fā)送一個數(shù)據(jù)包到收到對應(yīng)的ACK，所花費的時間
- RTO：重傳時間間隔
- TCP使用滑動窗口做流量控制與亂序重排
- 保證TCP的可靠性
- 保證TCP的流控特性
- 窗口數(shù)據(jù)的計算過程
窗口數(shù)據(jù)的計算過程
AdvertisedWindow = MaxRcvBuffer - (LastByteRcvd - LastByteRead)
TCP會話的發(fā)送方
滑動窗口的大小可以通過一定的策略動態(tài)調(diào)整
根據(jù)應(yīng)用根據(jù)自己處理能力的變化，通過本端TCP處理能力大小，對本端的發(fā)送窗口調(diào)整做流量限制
4. UDP
UDP的特點
- 面向非連接
- 不維護連接狀態(tài)，支持同時向多個客戶端傳輸相同的消息
- 數(shù)據(jù)包報頭只有8個字節(jié)，額外開銷較小
- 吞吐量只受限于數(shù)據(jù)生成速率、傳輸速率以及機器性能
- 盡最大努力交付，不保證可靠交付，不需要維護復(fù)雜的鏈接狀態(tài)表
- 面向報文，不對應(yīng)用程序提交的報文信息進行拆分或者合并
結(jié)論
TCP和UDP的區(qū)別
- 面向連接VS無連接
- 可靠性（握手、確認和重傳機制）
- 有序性（序列號）
- 速度（創(chuàng)建連接、排序等）
- 量級（源數(shù)據(jù)頭大小，TCP20個字節(jié)，UDP8個字節(jié)）
5. HTTP簡介
超文本傳輸協(xié)議HTTP主要特點
- 支持客戶/服務(wù)器模式
- 簡單快速，只需要傳輸請求方式，規(guī)定請求類型，規(guī)模小
- 靈活，允許傳輸各種類型數(shù)據(jù)，contentType標記
- 無連接，限制每次連接只處理一個請求，服務(wù)器處理完請求，即開始斷開客戶端連接，默認使用長連接以保證連接特性，keepline,每個獨立無法知道是否是長連接
- 無狀態(tài)，協(xié)議對事務(wù)處理無記憶，每次需要重復(fù)數(shù)據(jù)需要重傳
- HTTP請求結(jié)構(gòu)
HTTP請求結(jié)構(gòu)
- HTTP響應(yīng)結(jié)構(gòu)
HTTP響應(yīng)結(jié)構(gòu)
- 一個url請求在瀏覽器到訪問到背后經(jīng)歷了那些操作
- DNS解析，瀏覽器、系統(tǒng)、路由器、ips、域名、頂級域名、根域名
- tcp連接，三次握手
- 發(fā)送HTTP請求
- 服務(wù)器處理請求并返回HTTP報文
- 瀏覽器解析渲染
- 連接結(jié)束，四次揮手
- 五種可能的取值
- 1xx: 指示信息-表示請求已接受，繼續(xù)處理
- 2xx: 成功--表示請求已被成功接收、理解、接手
- 3xx: 重定向--要完成請求必須進行更進一步的操作
- 4xx: 客戶端錯誤--請求有預(yù)發(fā)錯誤或請求無法實現(xiàn)
- 5xx: 服務(wù)器端錯誤--服務(wù)器未能實現(xiàn)合法的請求
- Cookie和Session的區(qū)別
- Cookie:
- 是由服務(wù)器發(fā)給客戶端的特殊信息，以文本的形式存放在客戶端
- 客戶端再次請求的時候，會把Cookie回發(fā)
- 服務(wù)器接收到后，會解析Cookie生成與客戶端相對應(yīng)的內(nèi)容
-
Cookie的設(shè)置以及發(fā)送過程
Cookie設(shè)置以及發(fā)送過程
- Session
- 服務(wù)器端的機制，在服務(wù)器端上以散列表的形式保存的信息
- 解析客戶端請求并操作sessionId，按需保存狀態(tài)信息
- Session的實現(xiàn)方式
- 使用Cookie來實現(xiàn)
session實現(xiàn)
- 使用URL回寫方式來實現(xiàn)
- Cookie和Session的區(qū)別
- Cookie數(shù)據(jù)存放在客戶的瀏覽器上，Session數(shù)據(jù)存放在服務(wù)器上
- Session相對于Cookie更安全
- 若考慮減輕服務(wù)器負擔，應(yīng)該使用Cookie
6. HTTP和HTTPS的區(qū)別
HTTPS
超文本安全傳輸協(xié)議
HTTP和HTTPS協(xié)議對比
SSL（Security Sockets Layer,安全套接層）
- 為網(wǎng)絡(luò)通信提供安全及數(shù)據(jù)完整性的一種安全協(xié)議
- 是操作系統(tǒng)對外的API，SSL3.0后更名TLS
- 采用身份驗證和數(shù)據(jù)加密保證網(wǎng)絡(luò)通信的安全和數(shù)據(jù)的完整性
加密的方式
- 對稱加密：加密和解密都是用同一秘鑰
- 非對稱加密： 加密是用的秘鑰和解密是用的秘鑰是不相同的
- 哈希算法：將任意長度的信息轉(zhuǎn)換為固定長度的值，算法不可逆
- 數(shù)字簽名：證明某個消息或者文件是某人發(fā)出或被認同的
- HTTPS數(shù)據(jù)傳輸流程
- 瀏覽器將支持的加密算法信息發(fā)送給服務(wù)器
- 服務(wù)器選擇一套瀏覽器支持的加密算法，以證書的形式回發(fā)瀏覽器
- 瀏覽器驗證證書合法性，并結(jié)合證書公鑰加密信息發(fā)送給服務(wù)器
- 服務(wù)器使用私鑰解密信息，驗證哈希，加密響應(yīng)消息回發(fā)瀏覽器
- 瀏覽器解密響應(yīng)消息，并對消息進行驗證，之后進行加密交互數(shù)據(jù)
- HTTPS與HTTP區(qū)別
- HTTPS需要到CA申請證書，HTTP不需要
- HTTPS密文傳輸，HTTP明文傳輸
- 連接方式不同，HTTPS默認使用443端口，HTTP默認80端口
- HTTPS=HTTP+加密+認證+完整性保護,較HTTP安全
7. Socket
Socket是對TCP/IP協(xié)議的抽象，是操作系統(tǒng)對外開放的接口
socket作用域
Socket通信流程
Socket通信流程
image.png
