0
  • 聊天消息
  • 系統(tǒng)消息
  • 評論與回復(fù)
登錄后你可以
  • 下載海量資料
  • 學(xué)習(xí)在線課程
  • 觀看技術(shù)視頻
  • 寫文章/發(fā)帖/加入社區(qū)
會員中心
創(chuàng)作中心

完善資料讓更多小伙伴認識你,還能領(lǐng)取20積分哦,立即完善>

3天內(nèi)不再提示

tcp數(shù)據(jù)包接口封裝的介紹

FPGA之家 ? 來源:CSDN ? 作者:hasaki_code ? 2021-03-22 09:39 ? 次閱讀

TCP報文格式

TCP協(xié)議有著自己的數(shù)據(jù)包格式,這里把TCP的數(shù)據(jù)包稱為報文段(segment),TCP報文段封裝在IP數(shù)據(jù)報中發(fā)送,TCP報文段由TCP首部和TCP數(shù)據(jù)區(qū)組成,首部區(qū)域包含了連接建立與斷開、數(shù)據(jù)確認、窗口大小通告、數(shù)據(jù)發(fā)送相關(guān)的所有標志和控制信息。如下圖:

1c804092-8924-11eb-8b86-12bb97331649.png

首部的大小為20~60字節(jié),在沒有任何選項的情況下,首部大小為20字節(jié),與不含選項字段的IP報首部大小相同。TCP報文中的數(shù)據(jù)部分可以為空,例如在一個連接建立或斷開時,雙方交換的報文段僅有TCP首部;又如當一方?jīng)]有任何數(shù)據(jù)需要發(fā)送,則它需要使用不包含任何數(shù)據(jù)的報文段來發(fā)送確認信息。

1、源端口號和目的端口號兩個字段用于標識發(fā)送端和接收端應(yīng)用進程分別綁定的端口號。這兩個值加上IP數(shù)據(jù)報首部中的源IP地址和目的IP地址就能唯一確定一個TCP連接

2、32位序號字段標識了從TCP發(fā)送端到TCP接收端的數(shù)據(jù)字節(jié)編號,它的值為當前報文段中第一個數(shù)據(jù)的字節(jié)序號。在接收方,先計算出數(shù)據(jù)區(qū)數(shù)據(jù)的長度,然后使用首部中的序號字段,就能計算出報文最后一個字節(jié)數(shù)據(jù)的序號。當建立一個新連接時,握手報文首部中的SYN標志置1,此時,序號字段包含由發(fā)送方隨機選擇的初始序號ISN(Initial Sequence Number)。建立連接的報文(SYN)將占用一個數(shù)據(jù)編號,因此發(fā)送方隨后將要發(fā)送數(shù)據(jù)的第一個字節(jié)序號為ISN+1

3、32位確認序號只有ACK標志為1時才有效,它包含了本機所期望收到的下一個數(shù)據(jù)序號,確認常常和反向數(shù)據(jù)一起捎帶發(fā)送

4、4位首部長度指出了TCP首部的長度,以4字節(jié)為單位。需要這個值是因為選項字段的長度是可變的。由于這個字段有4bit,因此TCP最多有60字節(jié)的首部,如果沒有任何選項字段,首部長度應(yīng)該為5(20字節(jié))

5、在TCP首部中有6個標志bit,它們中的多個可同時被設(shè)置為1,它們告訴了接收端應(yīng)該如何解釋報文的內(nèi)容,比如一些報文段攜帶了確認信息、一些報文段攜帶了緊急數(shù)據(jù)、一些報文包含建立或關(guān)閉連接的請求。6個標志位的意義如下圖:

1d1e6826-8924-11eb-8b86-12bb97331649.png

6、窗口大小字段可看作捎帶的另一個例子,窗口通告可以附加在任何報文段中發(fā)送。在TCP發(fā)送一個報文時,可在窗口字段中填寫相應(yīng)值以通知對方自己的可用緩沖區(qū)大?。ㄒ宰止?jié)為單位),報文接收方需要根據(jù)這個值來調(diào)整發(fā)送窗口的大小。這個字段是16bit的,所以通告窗口的最大值為65535字節(jié)。窗口字段是實現(xiàn)流量控制的關(guān)鍵字段,當接收方向發(fā)送方通知一個大小為0的窗口時,將完全阻止發(fā)送方的數(shù)據(jù)發(fā)送

7、16位的緊急指針只有當緊急標志位URG置位時才有效,此時報文中包含了緊急數(shù)據(jù),緊急數(shù)據(jù)始終放在報文段數(shù)據(jù)開始的地方,而緊急指針定義出了緊急數(shù)據(jù)在數(shù)據(jù)區(qū)中的結(jié)束處,用這個值加上序號字段值就得到了最后一個緊急數(shù)據(jù)的序號

構(gòu)造TCP報文段

接下來,我們使用結(jié)構(gòu)體來定義TCP報文,該結(jié)構(gòu)體定義在level-ip的include/tcp.h文件中:

struct tcphdr {uint16_t sport;uint16_t dport;uint32_t seq;uint32_t ack_seq;uint8_t rsvd : 4;uint8_t hl : 4;uint8_t fin : 1,syn : 1,rst : 1,psh : 1,ack : 1,urg : 1,ece : 1,cwr : 1;uint16_t win;uint16_t csum;uint16_t urp;uint8_t data[];} __attribute__((packed));

這個結(jié)構(gòu)體的成員變量,與我們剛才介紹的TCP報文格式的每個字段是一一對應(yīng)的,這里不再重復(fù)解析。

tcp報文發(fā)送接口

tcp數(shù)據(jù)的發(fā)送接口tcp_transmit_skb,會在tcp建立可靠連接和數(shù)據(jù)發(fā)送時被多次調(diào)用,如三次握手、write()、read()等。在level-ip中,該接口函數(shù)保存在src cp_output.c文件中。如下圖:

static int tcp_transmit_skb(struct sock *sk, struct sk_buff *skb, uint32_t seq){struct tcp_sock *tsk = tcp_sk(sk);struct tcb *tcb = &tsk-》tcb;struct tcphdr *thdr = tcp_hdr(skb);/* No options were previously set */if (thdr-》hl == 0) thdr-》hl = TCP_DOFFSET;skb_push(skb, thdr-》hl * 4);thdr-》sport = sk-》sport;thdr-》dport = sk-》dport;thdr-》seq = seq;thdr-》ack_seq = tcb-》rcv_nxt;thdr-》rsvd = 0;thdr-》win = tcb-》rcv_wnd;thdr-》csum = 0;thdr-》urp = 0;if (thdr-》hl 》 5) {tcp_write_options(tsk, thdr);}tcp_out_dbg(thdr, sk, skb);thdr-》sport = htons(thdr-》sport);thdr-》dport = htons(thdr-》dport);thdr-》seq = htonl(thdr-》seq);thdr-》ack_seq = htonl(thdr-》ack_seq);thdr-》win = htons(thdr-》win);thdr-》csum = htons(thdr-》csum);thdr-》urp = htons(thdr-》urp);thdr-》csum = tcp_v4_checksum(skb, htonl(sk-》saddr), htonl(sk-》daddr));return ip_output(sk, skb);}

第12行:設(shè)置源端口號

第13行:設(shè)置目標端口號

第14行:自己發(fā)送的數(shù)據(jù)的起始序號

第15行:通知對方期望接收的下一字節(jié)的序號

在IP協(xié)議中,會對每個數(shù)據(jù)報進行編號,而在TCP中沒有報文編號的概念,因為它的目標是數(shù)據(jù)流傳輸,數(shù)據(jù)流由連續(xù)的字節(jié)流組成,盡管在上層可能用各種各樣的數(shù)據(jù)結(jié)構(gòu)和格式來描述數(shù)據(jù),但在TCP看來,數(shù)據(jù)都是字節(jié)流。TCP把一個連接中的所有數(shù)據(jù)字節(jié)都進行了編號,當然兩個方向上的編號是彼此獨立的,編號的初始值由發(fā)送數(shù)據(jù)的一方隨機選取,編號取值是0~2^32-1,比如發(fā)送方選擇的起始編號為20,且將要發(fā)送的數(shù)據(jù)長度為800字節(jié),那么字節(jié)編號將覆蓋20到819的范圍。當所有字節(jié)被編上號后,字節(jié)流會被分裝在若干個TCP報文中發(fā)送,此時TCP報文首部的字段能夠記錄它所運載數(shù)據(jù)的起始編號以及運載數(shù)據(jù)的長度。在接收端,可以根據(jù)這些信息對報文中數(shù)據(jù)進行排序和確認。例如,將上述的800字節(jié)放在三個報文段中來發(fā)送,前兩個報文段各裝載了300字節(jié)的數(shù)據(jù),最后一個報文裝載了200字節(jié)的數(shù)據(jù),則三個報文段攜帶的數(shù)據(jù)情況如下:

報文段1:起始序號:20,數(shù)據(jù)長度:300,序號范圍:20~319

報文段2:起始序號:320,數(shù)據(jù)長度:300,序號范圍:320~619

報文段3:起始序號:620,數(shù)據(jù)長度:200,序號范圍:620~819

接收方通過確認的機制來告訴發(fā)送方數(shù)據(jù)的接收狀況,這是通過向發(fā)送方返回一個確認號來完成的,確認號標識出自己期望接收到的下一個字節(jié)的編號,例如在上面的例子中,如果接收方接收到了報文段1,則它返回給發(fā)送方的確認號為320,表示自己期望收到數(shù)據(jù)編號為320的數(shù)據(jù);確認號是累計的,即如果發(fā)送方接收到確認號的值為620,說明接收方已經(jīng)正確接收了620編號以前的所有數(shù)據(jù),接收方可能是在收到兩個報文段后才發(fā)送的一個確認;還有一種情況,如果接收方只收到報文段1和3,那么它返回的確認號仍然是320,確認號始終表示接收方期望的下一字節(jié)數(shù)據(jù),盡管可能已有更高編號的數(shù)據(jù)被收到

第16行:保留位

第17行:設(shè)置滑動窗口大小

在數(shù)據(jù)發(fā)送端,所有數(shù)據(jù)流按照順序被組織在發(fā)送緩存中,什么時候發(fā)送數(shù)據(jù)以及發(fā)送的多少是由滑動窗口決定的,使用窗口滑動的概念可以達到很好的流量控制效果和擁塞控制效果。如下圖所示,滑動窗口可以看成定義在數(shù)據(jù)緩沖上的一個窗口,緩沖中存放了從應(yīng)用程序傳遞過來的待發(fā)送數(shù)據(jù),窗口能在緩沖上滑動,滑動窗口狀態(tài)決定了TCP能發(fā)送哪些數(shù)據(jù)?;瑒哟翱谳^大時, TCP可以在收到確認之前一次性地發(fā)送幾個報文段,這樣,可以使得網(wǎng)絡(luò)總是處于忙碌狀態(tài),提高網(wǎng)絡(luò)的吞吐率。當發(fā)送窗口較小時,能夠被發(fā)送的報文很少,在極端情況下,當發(fā)送窗口為0時,沒有任何報文能被發(fā)送,減少報文的發(fā)送是進行擁塞控制的最直接手段。因此,流量控制和擁塞控制的本質(zhì)在于對發(fā)送窗口的合理調(diào)節(jié)

第18行:校驗和設(shè)置為0

第19行:緊急指針設(shè)置為0,

TCP采用了緩沖機制來保證協(xié)議的高效性,在數(shù)據(jù)發(fā)送時,TCP內(nèi)核將延遲小分組數(shù)據(jù)的交付,它將等待足夠長的時間,以期待接收更多的應(yīng)用數(shù)據(jù),最后再一起發(fā)送;在接收數(shù)據(jù)時,TCP首先是先將數(shù)據(jù)放在接收緩沖中,只有在應(yīng)用程序準備就緒或者TCP協(xié)議認為時機恰當?shù)臅r候,數(shù)據(jù)才會被交付給應(yīng)用程序。上述緩沖機制是出于對網(wǎng)絡(luò)性能提升的考慮,但是它可能會妨礙某些應(yīng)用程序的使用。例如,兩個應(yīng)用程序進行交互式通信,一端應(yīng)用程序打算把用戶鍵入的字符發(fā)送給另一端應(yīng)用程序,并且期望對方立即響應(yīng)。在這種情況下,TCP的數(shù)據(jù)收集與延遲發(fā)送、緩沖遞交會給用戶帶來很不好的體驗。為了滿足交互式應(yīng)用場合的需求,TCP可以采用下面的方式解決這個問題。發(fā)送方應(yīng)用程序向TCP傳遞數(shù)據(jù)時,請求推送(push)操作,這時,TCP協(xié)議不會等待發(fā)送緩沖區(qū)被填滿,而是直接將報文發(fā)送出去。同時,被推送出去的報文首部中推送位(PSH)將被置1,接收端在收到這類報文時,會盡快將數(shù)據(jù)遞交給應(yīng)用程序,而不必緩沖更多的數(shù)據(jù)再遞交

tcp接收接口

tcp數(shù)據(jù)接收接口為tcp_in()函數(shù)。該函數(shù)在ip數(shù)據(jù)幀讀取接口ip_rcv()函數(shù)中調(diào)用。該函數(shù)保存在srcip_input.c文件中,我們來了解一下這個函數(shù),如下圖:

void tcp_in(struct sk_buff *skb){struct sock *sk;struct iphdr *iph;struct tcphdr *th;iph = ip_hdr(skb);th = (struct tcphdr*) iph-》data;tcp_init_segment(th, iph, skb);sk = inet_lookup(skb, th-》sport, th-》dport);if (sk == NULL) {print_err(“No TCP socket for sport %d dport %d ”,th-》sport, th-》dport);free_skb(skb);return;}socket_wr_acquire(sk-》sock);tcp_in_dbg(th, sk, skb);/* if (tcp_checksum(iph, th) != 0) { *//* goto discard; *//* } */tcp_input_state(sk, th, skb);socket_release(sk-》sock);}

第7行:從sk_buff中讀取ip首部信息

第8行:從ip數(shù)據(jù)包的data區(qū)域中讀取tcp數(shù)據(jù)信息

第10行:進行關(guān)鍵字段的大小端變換和計算應(yīng)答序號等

第12行:根據(jù)通信端口,查找管理該次tcp連接的結(jié)構(gòu)體sock

第20行:獲取該結(jié)構(gòu)體的讀寫鎖

第26行:數(shù)據(jù)遞交給tcp_input_state()函數(shù)處理,該函數(shù)會進行tcp通信狀態(tài)的變化,以及獲取把整理好的有序報文遞交給應(yīng)用程序。

總結(jié)

在對可靠性要求很高的場合下,使用TCP提供的傳輸性能是很合適的,TCP將兩個進程間傳遞的數(shù)據(jù)看作數(shù)據(jù)流的形式,兩個先后發(fā)出的TCP報文雖然在網(wǎng)絡(luò)中也是互不相關(guān)的傳輸,但是它們攜帶的數(shù)據(jù)之間卻具有關(guān)聯(lián)關(guān)系,因為TCP給傳輸?shù)拿總€字節(jié)數(shù)據(jù)一個唯一的編號。在接收端,所有數(shù)據(jù)將按照編號被順序組織起來,當所有數(shù)據(jù)接收成功后,TCP才把數(shù)據(jù)遞交給應(yīng)用層。應(yīng)用層不必擔心報文的亂序、重復(fù)、丟失等問題,TCP采用正面確認以及超時重傳等機制保證數(shù)據(jù)流能全部正確到達。

但是,我們這篇文章還沒涉及到這部分的內(nèi)容,但是我們已經(jīng)找到分析的突破口,那就是上面所提到的tcp_input_state()函數(shù),以后我們將在該函數(shù)里面剖析tcp種種可靠性機制。

原文標題:level-ip之tcp數(shù)據(jù)包接口封裝

文章出處:【微信公眾號:FPGA之家】歡迎添加關(guān)注!文章轉(zhuǎn)載請注明出處。

責任編輯:haq

聲明:本文內(nèi)容及配圖由入駐作者撰寫或者入駐合作網(wǎng)站授權(quán)轉(zhuǎn)載。文章觀點僅代表作者本人,不代表電子發(fā)燒友網(wǎng)立場。文章及其配圖僅供工程師學(xué)習(xí)之用,如有內(nèi)容侵權(quán)或者其他違規(guī)問題,請聯(lián)系本站處理。 舉報投訴
  • 數(shù)據(jù)
    +關(guān)注

    關(guān)注

    8

    文章

    6754

    瀏覽量

    88611

原文標題:level-ip之tcp數(shù)據(jù)包接口封裝

文章出處:【微信號:zhuyandz,微信公眾號:FPGA之家】歡迎添加關(guān)注!文章轉(zhuǎn)載請注明出處。

收藏 人收藏

    評論

    相關(guān)推薦

    艾體寶干貨 OIDA之四:掌握數(shù)據(jù)包分析-分析的藝術(shù)

    本文是OIDA方法系列的最后一部分,重點介紹數(shù)據(jù)包分析的“分析”階段。這一最后階段將剖析階段的精煉數(shù)據(jù)轉(zhuǎn)化為可操作的見解,使網(wǎng)絡(luò)管理員和安全專業(yè)人員能夠解決問題、優(yōu)化性能并增強安全性。分析是實現(xiàn)
    的頭像 發(fā)表于 09-24 11:47 ?126次閱讀
    艾體寶干貨 OIDA之四:掌握<b class='flag-5'>數(shù)據(jù)包</b>分析-分析的藝術(shù)

    請問DCTCP與DCUDP 的登錄數(shù)據(jù)包和心跳數(shù)據(jù)包與服務(wù)器端是如何交互的?

    DCTCP與DCUDP的登錄數(shù)據(jù)包和心跳數(shù)據(jù)包與服務(wù)器端是如何交互的?
    發(fā)表于 07-25 06:37

    使用AT SAVETRANSLINK時UDP數(shù)據(jù)包丟失怎么解決?

    Android 發(fā)送一個小 UDP 數(shù)據(jù)包(5 字節(jié))。這個小數(shù)據(jù)包被我的微控制器在UART上接收到。微控制器將更大的數(shù)據(jù)包(可變長度,約 100 字節(jié))發(fā)送回 UART。ESP在UART上接
    發(fā)表于 07-18 07:17

    能否在ESP結(jié)束之前通過串行端口停止傳入的UDP數(shù)據(jù)包的傳輸以解析下一個UDP數(shù)據(jù)包

    我正在做一個artnet節(jié)點, 它收到幾個 UDP 廣播數(shù)據(jù)包,工作正常,但是: 其中一些必須使用,其中一些必須丟棄, mi問題是:所有傳入的數(shù)據(jù)包都出現(xiàn)在帶有IPD命令的串行端口上, 并且我需要
    發(fā)表于 07-16 06:18

    請問如何使用AT CIPSEND或AT CIPSENDBUF發(fā)送多個數(shù)據(jù)包?

    我可以使用 AT CIPSEND 發(fā)送單個數(shù)據(jù)包。但是我必須發(fā)送一系列二進制數(shù)據(jù)包。如何使用AT CISEND或AT CIPSENDBUF發(fā)送多個數(shù)據(jù)包,什么是正確的算法? 到目前為止,我嘗試
    發(fā)表于 07-15 07:37

    TCP傳輸大量數(shù)據(jù)時丟失數(shù)據(jù)的原因?

    TCP用于傳輸大量數(shù)據(jù)時,要找到數(shù)據(jù)丟失的地方,當TCP傳輸大量數(shù)據(jù)時,數(shù)據(jù)包丟失,
    發(fā)表于 07-12 15:03

    在AN65974中短數(shù)據(jù)包和零長數(shù)據(jù)包是什么意思?

    在 AN65974 中,短數(shù)據(jù)包和零長數(shù)據(jù)包是什么意思? 非常感謝!
    發(fā)表于 05-30 07:41

    如何在AIROC GUI上獲取良好數(shù)據(jù)包和總數(shù)據(jù)包?

    使用 IQxel-MW LifePoint 作為發(fā)生器并發(fā)送波形BT_1DH5_00001111_Fs80M.iqvsg,但無法在 AIROC 工具中接收數(shù)據(jù)包。 以下是從 IQxel 發(fā)送
    發(fā)表于 05-22 06:39

    請問高端網(wǎng)絡(luò)芯片如何處理數(shù)據(jù)包呢?

    隨著網(wǎng)絡(luò)芯片帶寬的持續(xù)提升,其內(nèi)部數(shù)據(jù)包處理單元的工作負載也隨之增加。然而,如果處理單元無法與網(wǎng)絡(luò)接口的傳入速率相匹配,將無法及時處理數(shù)據(jù)包,這不僅會導(dǎo)致數(shù)據(jù)包隨機丟失,更會降低網(wǎng)絡(luò)的
    的頭像 發(fā)表于 04-02 16:36 ?511次閱讀
    請問高端網(wǎng)絡(luò)芯片如何處理<b class='flag-5'>數(shù)據(jù)包</b>呢?

    DPDK在AI驅(qū)動的高效數(shù)據(jù)包處理應(yīng)用

    傳統(tǒng)的數(shù)據(jù)包處理方式是數(shù)據(jù)包先到內(nèi)核最后再到用戶層進行處理。這種方式會增加額外的延遲和CPU開銷,嚴重影響數(shù)據(jù)包處理的性能。 DPDK 繞過內(nèi)核,在用戶空間中實現(xiàn)快速數(shù)據(jù)包處理。
    的頭像 發(fā)表于 02-25 11:28 ?793次閱讀
    DPDK在AI驅(qū)動的高效<b class='flag-5'>數(shù)據(jù)包</b>處理應(yīng)用

    使用P4和Vivado工具簡化數(shù)據(jù)包處理設(shè)計

    電子發(fā)燒友網(wǎng)站提供《使用P4和Vivado工具簡化數(shù)據(jù)包處理設(shè)計.pdf》資料免費下載
    發(fā)表于 01-26 17:49 ?0次下載
    使用P4和Vivado工具簡化<b class='flag-5'>數(shù)據(jù)包</b>處理設(shè)計

    tcp/ip協(xié)議包含哪幾層?tcp和udp有什么區(qū)別?

    網(wǎng)絡(luò)之間的接口,負責將數(shù)據(jù)包封裝成適合在物理網(wǎng)絡(luò)上傳輸?shù)母袷?,如以太網(wǎng)幀。 2. 網(wǎng)絡(luò)層:該層負責進行邏輯尋址,即為數(shù)據(jù)包添加源和目的的邏輯地址,實現(xiàn)
    的頭像 發(fā)表于 11-29 17:40 ?988次閱讀

    關(guān)于TCP協(xié)議總結(jié)的硬核干貨

    本文給出TCP報文格式的詳細說明,介紹網(wǎng)絡(luò)數(shù)據(jù)包傳遞中如何進行地址解析、建立TCP連接的三次握手過程以及斷開TCP連接的四次揮手過程。
    發(fā)表于 11-17 09:26 ?433次閱讀
    關(guān)于<b class='flag-5'>TCP</b>協(xié)議總結(jié)的硬核干貨

    如何解決tcp通信中的粘問題

    ,其實現(xiàn)實際是由系統(tǒng)內(nèi)核提供一片連續(xù)緩存(流緩沖)來實現(xiàn)應(yīng)用層程序與網(wǎng)卡接口之間的中轉(zhuǎn)功能。多個數(shù)據(jù)包被連續(xù)存儲于連續(xù)的緩存中,在對數(shù)據(jù)包進行讀取時由于無法確定發(fā)生方的發(fā)送邊界,而采用某一估測值大小來進行
    的頭像 發(fā)表于 11-11 11:40 ?1583次閱讀
    如何解決<b class='flag-5'>tcp</b>通信中的粘<b class='flag-5'>包</b>問題

    Linux場景下數(shù)據(jù)包是如何在協(xié)議層傳輸?shù)?/a>

    所有互聯(lián)網(wǎng)服務(wù),均依賴于TCP/IP協(xié)議棧。懂得數(shù)據(jù)是如何在協(xié)議棧傳輸?shù)?,將會幫助你提升互?lián)網(wǎng)程序的性能和解決TCP相關(guān)問題的能力。 我們講述在Linux場景下數(shù)據(jù)包是如何在協(xié)議層傳輸
    的頭像 發(fā)表于 11-11 11:33 ?1021次閱讀
    Linux場景下<b class='flag-5'>數(shù)據(jù)包</b>是如何在協(xié)議層傳輸?shù)? />    </a>
</div>                </div>            </div><!-- .main-wrap -->
        </article>

        <aside class=

    精選推薦

    更多
    • 文章
    • 資料
    • 帖子

    推薦專欄

    更多