沒有複雜的控制機制，面向無連線的通訊服務。
常用於：
包總量少的通訊
對傳輸、傳送、通訊、進行控制的協議。面向有連線的協議，只有在確認通訊對端存在時才會傳送資料，udp是對端不存在也會傳送。
通過檢驗和、序列號、確認應答、重發控制、連線管理以及視窗控制等機制實現可靠的傳輸。
① 通過序列號和確認應答提高tcp的可靠性
② 重發超時如何確定
③ 連線管理
④ tcp以段來傳送資料
⑤ 利用視窗控制提高速度
⑥ 視窗控制與重發控制
⑦ 流控制
⑧ 擁塞控制
tcp中沒有表示包長度和資料長度的字段，可由
ip層獲知
tcp的包長，有
tcp的包長可獲知資料的長度。
源埠號：
表示傳送端埠號，字段長16位。
目標埠號：
表示接收端埠號，字段長16位。
序列號：
字段長32位，序列號是指傳送資料所在的位置。每傳送一次資料，就累加一次該資料的位元組數的大小。
序列號不會從0或者
1 開始，而是建立連線時由計算機產生的隨機數作為初始值，通過
syn包傳給接收端主機，然後再由每**過去的位元組數累加到初始值上表示資料的位置。此外，在建立連線和斷開連線時傳送的
syn包和
fin包雖然本身不攜帶資料，但是也會作為乙個位元組增加對應的序列號。
確認應答號：
確認應答號字段長度為32位，是指下一次應該收到的資料的序列號。實際上，它是指已收到的確認應答減一為值得資料。傳送端在收到這個確認應答以後可以認為在這個序號之前的資料都已經被正常接收到了。
資料偏移：
該欄位表示tcp所傳輸的資料部分應該從
tcp包的哪個位開始計算，當然也可以把它看做是
tcp首部的長度。該字段長
4位，單位位元組
4位元組即
32位。如果該字段的值為
5，那說明從
tcp包的最一開始到
20位元組位置都是
tcp首部，餘下部分是
tcp資料。
保留該欄位主要是為了以後擴充套件使用，一般設定為0，但即使收到的包中該字段不為
0，也不會丟棄。
控制位每一位從左至右分別為cwr,ece,urg,ack,psh,rst,syn,fin。
視窗大小
該字段長為16，用於通知從相同
tcp首部的確認應答號所指位置開始能夠接受資料大小，
tcp不允許傳送超過此處所示大小的資料。如果視窗大小為
0，表示視窗探測，以了解最新的視窗大小。
校驗和同udp
緊急指標
本報文中的緊急資料的指標。
選項提高tcp的效能。
除去資料部分正是udp的首部，
udp首部由源埠號、目標埠號、包長、校驗和組成。
包長度該欄位儲存了udp首部的長度跟資料的長度之和。
校驗和校驗和是為了提供可靠的udp首部和資料而設計。
外包中的「小事情」
談到外包 管理，不知別的cio認為最困難的是什麼？對我來說，在外包 管理環節當中，有乙個我一直沒有做得非常有體系的環節 人天的計算。我曾與一位業界前輩交流這個困擾，他說 做了10多年 it 怎麼可能連人天計算這種小事情都搞不定呢？不可否認，他說的有些道理，人天計算的確看起來像是 小事情 但是在專案展...
測試中的小事情
開發不能有的心態 不要妄自揣測誰會使用自己的應用，因為誰都有可能。不要以為每個訪問者都和自己一樣精通計算機知識，他們或許對計算機知識一無所知。不要樂觀地認為使用者會因為 導航體驗不佳而還能保持瀏覽的興趣，因為有很多競爭對手。不要天真的以為自己了解所有使用者對於效能和資訊的終極需求。上面的四句話，是對...
小事情大道理（一）
最近發生了好多的事情，但每件事情都凸顯了我思想上的不成熟。之前我們 10期內部也就作品展出現的問題頭腦風暴，有點效果，但是甚微。昨天 9期的師哥師姐和我們一起頭腦風暴，通過出現的問題，刨根問底，分析每個人的潛在想法。歸根結底是我們沒有意識到公尺老師的價值。其實我知道公尺老師很重要，但重要的程度是多少...