區分協議部分和資料部分

2022-09-20 20:36:09 字數 1264 閱讀 5106

參考:

如何確定tcp資料報長度)

協議中body長度的確定)

在tcp資料報處理的實戰中,總會確定payload的長度

但是呢,tcp頭部中沒有確定的tcp_len長度,非常的煩

所以一般如下確定payload長度:

從ip報頭(ip .len)中提取「總長度」,然後減去「ip報頭長度」(ip .hdr_len)和「tcp頭長度」(tcp.hdr_len)。

在核心中也就是 ip->tot_len - ip->len -hdr_len(tcp)。

背景:

http請求是基於tcp協議之上的,那麼,當客戶端在發起請求前,需要先與服務端建立tcp連線,而每一次的tcp連線是需要三次握手來確定的,如果客戶端與服務端之間網路差一點,這三次互動消費的時間會比較多,而且三次互動也會帶來網路流量。當然,當連線斷開後,也會有四次的互動,當然對使用者體驗來說就不友好了。

定義:而http請求是請求應答式的,如果我們能知道每個請求頭與響應體的長度,那麼我們是可以在乙個連線上面執行多個請求的,這就是所謂的長連線。

前提:先確定請求頭與響應體的長度。

對於請求頭:

a、如果當前請求需要有body,如post請求,那麼nginx就需要客戶端在請求頭中指定content-length來表明body的長度。

b、如果請求頭不需要body,遇到兩個連續回車時,即可確定請求頭結束。

對於應答體:

a、對於http1.0協議來說,如果響應頭中有content-length頭,則以content-length的長度就可以知道body的長度了,客戶端在接收body時,就可以依照這個長度來接收資料,接收完後,就表示這個請求完成了。

而如果沒有content-length頭,則客戶端會一直接收資料,直到服務端主動斷開連線,才表示body接收完了。

b、而對於http1.1協議來說,如果響應頭中的transfer-encoding為chunked傳輸,則表示body是流式輸出,body會被分成多個塊,每塊的開始會標識出當前塊的長度,此時,body不需要通過長度來指定。

如果是非chunked傳輸,而且有content-length,則按照content-length來接收資料。否則,如果是非chunked,並且沒有content-length,則客戶端接收資料,直到服務端主動斷開連線。

部分和問題

時間限制 1000 ms 記憶體限制 65535 kb 難度 2 描述 給定整數a1 a2 an,判斷是否可以從中選出若干數,使它們的和恰好為k。輸入 首先,n和k,n表示數的個數,k表示數的和。接著一行n個數。1 n 20,保證不超int範圍 輸出如果和恰好可以為k,輸出 yes 並按輸入順序依次...

部分和問題

時間限制 1000 ms 記憶體限制 65535 kb 難度 2 描述 給定整數a1 a2 an,判斷是否可以從中選出若干數,使它們的和恰好為k。輸入 首先,n和k,n表示數的個數,k表示數的和。接著一行n個數。1 n 20,保證不超int範圍 輸出如果和恰好可以為k,輸出 yes 並按輸入順序依次...

部分和問題

給定n 個整數ai 求是否可選出若干個數,使它們的和恰好為k n 20 example 1 n 4 a k 13 include include using namespace std intn,k,a 22 suit 22 num 0 stack int p bool dfs inti,intsu...