国产成人精品无码青草_亚洲国产美女精品久久久久∴_欧美人与鲁交大毛片免费_国产果冻豆传媒麻婆精东

18143453325 或 在線咨詢 在線咨詢
18143453325 或 在線咨詢
所在位置： 首頁 > 營銷資訊 > 建站知識 > 再談Http和Https及TCP/UDP/IP協(xié)議分析，面試官都驚訝的網(wǎng)絡見解

再談Http和Https及TCP/UDP/IP協(xié)議分析，面試官都驚訝的網(wǎng)絡見解

時間：2023-02-19 20:58:01 | 來源：建站知識

時間：2023-02-19 20:58:01 來源：建站知識

再談Http和Https及TCP/UDP/IP協(xié)議分析，面試官都驚訝的網(wǎng)絡見解：

一. 再談HTTP再理解

實際上，上網(wǎng)的大部分行為都是在進行進程間通信.. 也就是不斷地獲取信息和發(fā)送信息

比如:

1. 把服務器上面地資源數(shù)據(jù)拿到本地 (短視頻, 網(wǎng)頁)

2. 把本地地數(shù)據(jù)推送到服務器 (搜索， 注冊，登錄，下單)

http的底層一般是基于傳輸層協(xié)議tcp實現(xiàn)的

  1. 瀏覽器和web服務器三次握手建立TCP連接
  2. 瀏覽器進行 req (request請求)
  3. 服務器進行 rep （reply響應）
  4. 瀏覽器和web服務器四次揮手斷開TCP連接
http是超文本傳輸協(xié)議, 在底層實現(xiàn)中涉及了很多地文本解析

再談http地無狀態(tài): 指協(xié)議不具備記憶地能力, 不需要對于進程間通信地歷史狀態(tài)進行保存, 服務器是無法判斷用戶是否歷史上曾經(jīng)打開過這個網(wǎng)頁了的. 也就是上一次打開網(wǎng)頁和這一次打開相同的網(wǎng)頁互相不關聯(lián), 也不知道你上次打開過. （不會記憶）這個就叫做無狀態(tài)

request 報文

response 報文

主要請求方法解釋：

上述便是需要Content-Length的原因, 獲知正文是否存在以及正文長度

再次手寫一個便理解的簡單的http://httpserver.cc 的服務器, 使用C++完成

#include <iostream>#include <unistd.h>#include <sys/types.h>#include <sys/socket.h>#include <arpa/inet.h>#include <strings.h>#include <signal.h>#include <string>#include <fstream> #define ERR_EXIT(m) / do { std::cerr << m << std::endl; close(EXIT_FAILURE); } while(0)typedef struct sockaddr SA; int main() { signal(SIGCHLD, SIG_IGN);//信號處理, 避免子進程僵尸 int listenfd, connfd, pid; socklen_t addLen; struct sockaddr_in clientAdd, serveAdd; if ((listenfd = socket(AF_INET, SOCK_STREAM, 0)) == -1 ) { ERR_EXIT("socket"); } int flag = 1; setsockopt(listenfd,SOL_SOCKET, SO_REUSEADDR, &flag, sizeof(flag)); //SO_REUSEADDR BOOL 允許套接口和一個已在使用中的地址捆綁（參見bind()） //SOL_SOCKET固定level設置 bzero(&serveAdd, sizeof(serveAdd));//清空 serveAdd.sin_family = AF_INET;//協(xié)議家族 serveAdd.sin_port = htons(8080);//默認80端口 serveAdd.sin_addr.s_addr = htonl(INADDR_ANY); //INADDR_ANY == 0 作用適配地址 if (bind(listenfd, (SA*)&serveAdd, sizeof(serveAdd)) == -1) { ERR_EXIT("bind"); } //3： 等待隊列syn隊列的長度 if (listen(listenfd, 3) == -1) { ERR_EXIT("listen"); } while (1) { if ((connfd = accept(listenfd, (SA*)&clientAdd, &addLen)) == -1) { ERR_EXIT("accept"); } pid = fork();//fork出來子進程 if (pid) { close(connfd); //父進程關閉connfd然后僅僅進行l(wèi)isten. SIGCHLD會自動收尸 } else { close(listenfd);//子進程進行發(fā)送響應報文 char buffer[1024]; recv(connfd, buffer, sizeof(buffer), 0); std::cout << "#############################http request begin#############################################"<<std::endl; //打印recv的來自客戶端的請求并且輸出請求信息 std::cout << buffer << std::endl; std::cout << "#############################http request end#############################################"<<std::endl; std::ifstream ifs("./index.html"); if (ifs) { int len; ifs.seekg(0L, ifs.end);//定位到文件末尾 len = ifs.tellg();//獲取文件長度 ifs.seekg(0L, ifs.beg);//回到文件開頭 char *file = new char[len]; ifs.read(file, len);//讀取正文, 字符串形式讀取 ifs.close(); //開始處理響應: std::string status_line = "HTTP/1.1 200 OK/r/n";//狀態(tài)行 std::string reply_header;//響應頭部 reply_header +="Content-Length: " + std::to_string(len) + "/r/n"; std::string black = "/r/n"; send(connfd, status_line.c_str(), status_line.size(), 0); send(connfd, reply_header.c_str(), reply_header.size(), 0); send(connfd, black.c_str(), black.size(), 0); send(connfd, file, len, 0); delete [] file; } close(connfd); exit(EXIT_SUCCESS); } } close(listenfd); return 0;}

服務器IP : 端口號 可以訪問, 服務器可能沒有開放端口, 可以在購買的服務器安全組中設置

相關視頻推薦

《tcpip詳解卷一》：150行代碼拉開協(xié)議棧實現(xiàn)的篇章

網(wǎng)絡原理tcp/udp，網(wǎng)絡編程epoll/reactor，面試中正經(jīng)“八股文”

學習地址：C/C++Linux服務器開發(fā)/后臺架構師

需要C/C++ Linux服務器架構師學習資料加qun812855908獲?。ㄙY料包括C/C++，Linux，golang技術，Nginx，ZeroMQ，MySQL，Redis，fastdfs，MongoDB，ZK，流媒體，CDN，P2P，K8S，Docker，TCP/IP，協(xié)程，DPDK，ffmpeg等），免費分享

二. HTTP對比學習HTTPS

HTTPS ： 是以安全為目標的HTTP通道, 通俗說就是安全版本的HTTP，

為啥需要HTTPS

為啥叫做HTTPS , S的含義， SSL：加密，在HTTP下加入SSL層 (解決上述問題)

SSL操作步驟：

  1. 驗證服務器端
  2. 允許客戶端和服務端選擇加密算法和密碼, 確保雙方都支持
  3. 驗證客戶端
  4. 使用公鑰加密技術來生成共享加密數(shù)據(jù)
  5. 創(chuàng)建一個加密的SSL連接
  6. 基于該SSL連接傳遞HTTP請求
HTTPS的主要作用：一個是建立一個信息安全通道，用來保證數(shù)據(jù)傳輸?shù)陌踩?，另外一個就是驗證網(wǎng)站的真實性了...

HTTP和HTTPS的區(qū)別如下:

  1. https協(xié)議需要 ca申請證書，一般免費的證書較少，因而是需要一定費用的]
  2. http是超文本傳輸協(xié)議，信息是明文傳輸，https則是具有安全性的SSL加密傳輸協(xié)議
  3. http 和 https使用的是完全不同的連接方式，用的端口也是不一樣的。前者是80端口 后者是443端口
  4. http的連接很簡單，是無狀態(tài)的；https協(xié)議是由 SSL + HTTP協(xié)議構建的可進行加密傳輸，身份認證的網(wǎng)絡協(xié)議，比http協(xié)議安全.
  5. 在OSI模型中，HTTP工作在應用層，而HTTPS工作在傳輸層
寫傳輸層協(xié)議之前先介紹一個四元組的概念: 網(wǎng)絡通信的實現(xiàn)就是基于四元組的，不論是TCP還是UDP 要想將數(shù)據(jù)從一端傳入到另外一端，就必須明確對端的二元組, 雙方如果都要相互通信就要確定四元組

首先我們確定要雙方不同主機上的不同進程間進行通信, 必須確定雙方的 ip + port why?

上述圖主要是為了引出為啥要 ip

上述圖是為了引出為啥需要 port

三.TCP協(xié)議 （三次握手四次揮手細節(jié)過程理解在之前的博文中有詳細圖解）

報文分析

源 / 目的端口，那就是老身常談了, 從哪個進程來，到哪個進程去

32位序號和確認序號 （原諒咱留個小疑惑，后面解釋，和重傳機制有關系）

4位TCP報頭長度: 表示該TCP頭部有多少個32位bit(有多少個4字節(jié)); 所以TCP頭部最大長度是15 * 4 = 60 （基本衡量單位都是4字節(jié)為最小單位） 因為首部長度是4位 最大就是15; 所以最大首部長度就是 15 * 4 (最小單位) = 60字節(jié)

6位標志位:

16位窗口大?。ㄏ攘魝€疑，其實就是存儲接收緩沖區(qū)還剩下的大小, 和流量控制有關）

16位校驗和: 發(fā)送端填充, CRC校驗. 接收端校驗不通過, 則認為數(shù)據(jù)有問題. 此處的檢驗和不光包含TCP首部, 也 包含TCP數(shù)據(jù)部分

6位緊急指針: 標識哪部分數(shù)據(jù)是緊急數(shù)據(jù)

tcp緩沖區(qū)概念的引入 (解釋流量控制):

tcp連接建立之后是存在接收和發(fā)送內(nèi)核緩沖區(qū)的....

send 還有 recv這些接口都不是直接將數(shù)據(jù)發(fā)送到網(wǎng)路中，也不是直接從網(wǎng)路中讀取數(shù)據(jù)的...

而是存在發(fā)送緩沖區(qū)和接收緩沖區(qū)的概念, 這些都是內(nèi)核緩沖區(qū)。。。同樣之前的窗口大小其實就是接收緩沖區(qū)還剩余的大小, 支持流量控制 (你發(fā)送的數(shù)據(jù)不能超過，不然就滿了)

接收緩沖區(qū)大寫也對應著流量控制：why？ 如何理解

接收端處理數(shù)據(jù)的速度是有限的. 如果發(fā)送端發(fā)的太快, 導致接收端的緩沖區(qū)被打滿, 這個時候如果發(fā)送端繼續(xù)發(fā)送, 就會造成丟包, 繼而引起丟包重傳等等一系列連鎖反應.

因此TCP支持根據(jù)接收端的處理能力, 來決定發(fā)送端的發(fā)送速度. 這個機制就叫做流量控制(Flow Control)

所以窗口大小就是接收端處理能力的代表 (發(fā)送端接收到窗口大小會根據(jù)窗口大小進行調(diào)節(jié)自己的發(fā)送速度，進行流量控制) 填充窗口字段就是填充的自身的接收緩沖區(qū)中剩余空間的大小 （此窗口也稱為接收窗口）

窗口大小字段越大, 說明網(wǎng)絡的吞吐量越高;

確認應答(ACK)機制的理解 （編序號）

ACK應答的含義就是: acknum 之前的序號的數(shù)據(jù)包我都已經(jīng)收到了,下一次你從acknum開始發(fā)送吧

超時重傳機制

超時重發(fā)指的是因為網(wǎng)絡環(huán)境的擁堵阻塞導致了在很長一段時間發(fā)送方都沒有等到自己之前發(fā)送包的回音 （于是TCP默認是丟包）然后會采取重傳措施

由于重傳機制，會存在一些情況是 之前因為網(wǎng)絡擁堵的數(shù)據(jù)包 在網(wǎng)絡環(huán)境恢復之后正常傳入到對端, 導致對端可能會收到多份重復的數(shù)據(jù)報文，不過嘞因為序號的存在可以通過需要進行簡單的去重即可

但是這個超時時間如何確認??? 多少算合適，這個也是個置得討論的問題

  1. 最理想的情況下, 找到一個最小的時間, 保證 "確認應答一定能在這個時間內(nèi)返回".
  2. 但是這個時間的長短, 隨著網(wǎng)絡環(huán)境的不同, 是有差異的.
  3. 如果超時時間設的太長, 會影響整體的重傳效率;
  4. 如果超時時間設的太短, 有可能會頻繁發(fā)送重復的包;
TCP為了保證無論在任何環(huán)境下都能比較高性能的通信, 因此會動態(tài)計算這個最大超時時間.(抓核心主題，據(jù)網(wǎng)絡環(huán)境而生 超時時間)

  1. Linux中(BSD Unix和Windows也是如此), 超時以500ms為一個單位進行控制, 每次判定超時重發(fā)的超時 時間都是500ms的整數(shù)倍.
  2. 如果重發(fā)一次之后, 仍然得不到應答, 等待 2*500ms 后再進行重傳.
  3. 如果仍然得不到應答, 等待 4*500ms 進行重傳. 依次類推, 以指數(shù)形式遞增.
  4. 累計到一定的重傳次數(shù), TCP認為網(wǎng)絡或者對端主機出現(xiàn)異常, 強制關閉連接.

滑動窗口理解

滑動窗口下的丟包問題分析

第一種是ACK丟失

如上述情況下，滑動窗口的ACK部分丟失其實不是很緊要，因為可以通過后序的ACK確認；ACK一旦確認之后代表的含義是 默認之前的所有序列數(shù)據(jù)都已經(jīng)全部收到了

情況2是數(shù)據(jù)包傳過去的時候就丟失了

單獨解釋一下 快重傳 : 就是說在接收方收到一個失序的報文段的時候就立即會發(fā)出重復確認。（目的在于使得發(fā)送方盡早地知道說自己有報文丟失了，沒有到達對面）接收方地意思就是 哥你確定你發(fā)的是對的，我前面的報文都還沒收到 （順序不對呀）三次之后發(fā)送方反應過來直接重傳，不再等待超時

擁塞控制

TCP小結

TCP是面向連接的，可靠的，基于字節(jié)流的傳輸層通信協(xié)議

如何保證可靠性:

性能提升上面：

1. 采取了滑動窗口

2. 快速重傳 (不需要等待超時，三次對端提醒之后自動重傳)

基于TCP應用層協(xié)議 HTTP HTTPS SSH Telnet FTP SMTP

TCP最大連接數(shù)的分析(面試?？?(從四元組的角度入手)

四.UDP協(xié)議

先從報文分析入手

UDP的特征: 什么是無連接，不可靠，關鍵為什么它如此的不穩(wěn)定但是在現(xiàn)在的短視頻 音視頻通話 DNS ARP這些全部都還使用的是UDP作為傳輸層協(xié)議

首先是無連接, 連接是什么: 連接算是一端到另外一端的不存在的一根線 (抽象的來說，這個是我的個人理解, 連接的過程也就是三次握手的過程)對于三次握手不理解的可以看我前文鏈接存在詳解

首先不論是有連接還是無連接, 我們核心應該確定的是什么? 確定四元組，對了四元組，無連接也可以進程間通信，只不過每一次必須傳入四元組, 但是口說無憑, 咱看看接口唄。對比一下:

為什么UDP是不可靠連接?

因為UDP沒有TCP的哪些為了保證可靠性的機制: 比如超時重傳機制，擁塞控制，流量控制機制，為數(shù)據(jù)包編號排序等...

思考為啥UDP如此不可靠我們還必須要使用它, 而且還會盡量的使其變得可靠, 還要專門做UDP可靠性設計，這個不是多次一舉嗎. 不如直接使用TCP?

首先解釋UDP相比TCP為什么相對實時性好, 在時間上更短, 更加快速。。。

以上是從不必要的三次握手建立連接上解釋這個速度問題, 為啥UDP更快

而且在進行數(shù)據(jù)傳輸?shù)臅r候TCP還會存在一定的時間限制，時間閾值，超過這個時間就需要進行重傳， 重傳也會導致延遲性，向我們的qq聊天呀就經(jīng)常出現(xiàn)這樣的延遲現(xiàn)象，很明顯底層應當是采取的TCP作為傳輸層協(xié)議.

根據(jù)上述的延遲解釋一下音視頻通話為例解釋下為啥使用UDP而不是TCP？

一句話解釋：就是通話延遲的問題，我們qq上發(fā)個消息是無所謂，延遲下我們可以等會看嘛，但是你在跟別人搞音視頻，像抖音這些，或者各種視頻，這個要是通話延遲，幾秒前說的話幾秒后出來了你這個還搞個屁呀, 還說得清嘛，這個很明顯需要實時通話，正是這樣的場景存在所以UDP必然是需要的。。。而且現(xiàn)在音視頻（短視頻）如此火爆更是少不了UDP了

我們再從另外一個角度來分析一下這個問題, 服務端壓力上面來考慮。。。

再談UDP可靠傳輸?shù)脑O計。。。

現(xiàn)有的udp可靠傳輸協(xié)議就是KCP了，感興趣的還真有必要得去深入研究一下，我個人是研究深度還不夠，先暫且淺顯的聊一聊這個UDP可靠傳輸設計的一些基本的東西，KCP要是將來我的理解深入足夠會盡力刨析一下...

首先既然提到了MTU 先解釋一下 MTU是個啥玩也.

總結UDP可靠傳輸?shù)膶W習:

五. 對比TCP和UDP的細節(jié)

總結本文

關鍵詞：驚訝,網(wǎng)絡,分析,協(xié)議

74
73
25
news

版權所有? 億企邦 1997-2025 保留一切法律許可權利。

為了最佳展示效果，本站不支持IE9及以下版本的瀏覽器，建議您使用谷歌Chrome瀏覽器。 點擊下載Chrome瀏覽器
關閉