一键复制
在日常的学习、工作、生活中，肯定对各类范文都很熟悉吧。大家想知道怎么样才能写一篇比较优质的范文吗？接下来小编就给大家介绍一下优秀的范文该怎么写，我们一起来看一看吧。
连接协议tcp篇一
甲方：(以下简称：甲方)
乙方：(以下简称：乙方)
依照《中华人民共和国民法典》有关规定，为明确双方权力义务，经甲、乙双方共同协商，就乙方对甲方承施的( )工程项目结构中的钢筋部分进行成型加工(含机械连接接头)配送事宜达成一致，同意订立本合同。
一、 工程概况：
( )项目位于( )，工程建筑面积：( )平方米，结构封顶日期 年 月 日。
二、 加工事宜：
甲方向乙方订购的成型钢筋所使用的线材、圆钢及螺纹钢的原材料为首钢、唐钢、宣钢、邢钢产品。如加工过程中乙方使用非合同规定的原材料时，须事先以书面形式通知甲方，经甲方授权委托人签字同意后，方可实施加工(如甲方在二十四小时内未能做出书面回复，则视为甲方同意乙方意见)乙方应严格按照甲方提供的配筋单中标注的规格、图示尺寸、数量进行加工。
三、 重量结算依据：
根据甲方提供的本工程成型钢筋配筋单，经乙方进行理论重量计算，作为本合同重量结算依据。结算重量单位为吨，重量数值经四舍五入保留小数点后三位。
四、 甲方工作：
1、 合同签订时甲方提供授权经办人签字字体样本作为本合同附件，并明确其授权范围。
2、 合同签订时，甲方应以书面的形式对乙方进行技术交底。交底资料中应详细说明所承揽项目流水作业段划分平面布置图，计划施工进度(月度计划及结构封顶时间排序计划)，以及成型钢筋箍筋平直部分的长度，特殊角度的工艺要求等。
3、 甲方应于每月25日前向乙方提供次月本工程所用成型钢筋的配筋单(特殊情况补充时须提前3日，数量不得超过30吨)，配筋单上的目录应注明起止编号、使用部位，且每张配筋单上须有甲方授权经办人签字，并在工程名称处加盖甲方公章后生效(签字人字体样本附后)
4、 成型钢筋加工制作过程中，甲方有权随时到乙方加工现场就加工质量进行抽检工作，乙方有义务积极配合。
5、 如甲方工程工期延误，仍按照本合同执行。
6、 成型钢筋出库前，甲方应指定专人进行清料工作，待甲方清料人员对成型钢筋数量确认签字后乙方方可发货(签字人签字样本附后)
7、 成型钢筋每车装车数量不得小于10吨。
五、 乙方工作：
1、 合同签订时，乙方应积极组织资源，确保甲方工程项目施工进度。
2、 乙方接到甲方提供的成型钢筋配筋单时，应认真校对，如规格、数量、图示尺寸、标注无法正确识别时，甲方授权委托人应在12小时内书面确认，否则免除乙方的供货责任。
3、 乙方所使用的钢筋机械连接工艺为剥肋滚压直螺纹。
4、 乙方所配送的成型钢筋必须提供原材料出厂质量证明合格证书。
5、 乙方制作的成型钢筋应符合甲方配筋单的要求，并在产品上以标牌的形式标注成型钢筋使用部位的编号、尺寸、几何图形、数量，每一编号的钢筋提供一张标牌，固定在钢筋打捆处。
6、 乙方有责任协助甲方人员在乙方加工现场对成型钢筋进行清料及装车工作，并按甲方的要求运至施工现场。
六、 设计变更：
1、施工过程中如出现不可预见及设计变更，甲方应以书形式及时向乙方提供补充配筋单，并标注“急配”字样及需用时间(供应时间甲、乙双方协商确定)，如需增加费用以甲、乙双方协商为准。
2、设计变更及修改过程中，乙方已投入加工生产部分按合同规定价格结算，如出现以大改小损耗部分及所需增加人工费用部分由甲方承担。
七、 产品质量要求：
1、 乙方使用的原材料必须符合：《低碳钢热轧圆盘条》;《钢筋混凝土用热轧光圆钢筋》;《钢筋混凝土用热轧带肋钢筋》的规定。
2、 产品质量检验应符合《混凝土结构工程施工质量验收规范》中的第五章5.3.4及《建筑结构长城杯工程质量评审标准》的规定。
3、 直螺纹连接接头应符合《钢筋机械连接通用技术规程》、《钢筋等强度剥肋滚压直螺纹连接技术规程》中的规定。
八、钢筋原材复试及资料：
1、钢筋原材料在投入使用前，乙方负责原材料的取样及送检工作，委托检验的机构必须是经北京市建委审核合格具有见证试验资质的检测中心。
2、根据《北京市建设工程施工试验实行有见证取样和送检制度的暂行规定》，甲方及监理单位进行见证取样时应持正式书面通知，乙方应积极配合取样工作，其检测机构及费用由甲方负责。
3、根据《建筑工程资料管理规程》规定，乙方在成型钢筋配送至施工现场后，提供《半成品出厂合格证》表式c4-5附钢筋原材料出厂材料质量证明书及产品铭牌、原材料复试检验报告。
九、合同价款及付款方式：
1、 合同价款：
(1) 本合同成型钢筋的结算单价为人民币( )元/吨(钢筋不分品种、规格均为本单价)，上述结算单价包括材料费、成型制作费、包装费、装车费、运输费等交付甲方使用前的费用(卸车及费用由甲方承担)不包括原材料复试及机械连接接头费用。
(2) 三级螺纹钢的结算价格在本合同结算单价基础上加( )元/吨。
(3) 钢筋机械连接头 元/单头(钢筋不分品种、规格加工套丝，并戴好保护帽)，按照配筋单图示数量进行签收。
(4) 钢筋原材料复试费用按照《半成品出厂合格证》实际标注数量进行签收。
(5) 合同执行过程中如钢厂价格调整，其结算价格以首钢现货市场、北京市京首贸易服务有限责任公司、北京市恒物金属材料有限公司其中之一公布的调价政策通知作为价格调整的依据，由乙方以书面形式送达甲方，调价依据在送达后24小时内，甲方予以书面确认或经甲、乙双方协商签订本合同补充协议。
(6) 本合同成型钢筋总量为( )吨，总价款(人民币)( )元，(大写： )总价中不包括原材料复试及机械连接接头费用。
(7) 验货地点：
2、 付款方式：
(1) 本合同结算期为上月26日至本月25日。甲方在送达本月成型钢筋加工配筋单时，同时将货款支票一并送达(乙方预收当月货款80%，余款20%月末前结清)，乙方经配筋单录入生成系统确认数量后划转。
(2) 钢筋机械连接接头加工费用随成型钢筋货款同时划转。
(3) 原材料复试费用依据《半成品出厂合格证》中确认数量经甲方签认，在月末前结清。
(4) 本合同总价款如发生变化，超出部分甲方应按配筋单数量以现款形式预付给乙方。
十、违约责任：
1、 乙方没有按照本合同规定的质量、规格、数量等提供产品，甲方有权退货，乙方应承担所发生的全部装卸及运输费用。
2、 合同执行过程中，如遇钢厂市场价格调整，根据合同第九章(5)条，甲方接到乙方调整价格依据24小时内未能书面确认或签订补充协议，乙方有权停止继续供货。
3、 甲方如未能按合同规定要求将配筋单及货款同时送达，乙方有权拒绝接受配筋单及加工任务。
4、 由于甲方清料人员不能及时清料，致使配送工作无法正常进行，所造成的工期延误，责任由甲方承担，同时工期顺延。
5、 甲方如未能按合同规定时间付款，逾期乙方有权停止继续供货，并向甲方按每延期一日收取至货物发出之日起计算每天3元/吨违约金。
6、 乙方未能在甲方计划工期内将成型钢筋送至施工现场，甲方应按当日该批送达数量以50元/吨扣除乙方应承担的违约责任。
十一、争议：
本合同在执行过程中发生争议或纠纷，双方应友好协商解决。如协商未果，双方一致同意在乙方所在地人民法院提起诉讼。
十二、其它：
1、 本合同签订时，甲、乙双方需相互提供企业法人营业执照复印件、企业法人代码复印件、资质证书复印件、法人授权委托书原件、工程项目施工合同原件等相关法律文件，并注明相关文件的授权使用范围。
2、 如遇人力不可抗力因素(民法153条规定)致使合同无法正常履行时，双方应另行协商。
3、 合同附件为本合同有效文件组成部分。
十三、本合同一式肆份，即正本、副本各两份，甲、乙双方各执正本、副本壹份，具有同等法律效力。
十四、本合同自甲、乙双方盖章并经合法授权人签字后生效。
十五、本合同未尽事宜，执行《中华人民共和国民法典》的有关规定。
本合同变更条款及内容(销售部门填写)
甲方(盖章) 乙方(盖章)
法定代表人： 法定代表人：
委托代理人： 委托代理人：
联系电话： 联系电话：
公司地址： 公司地址：
签订日期： 签订日期：
签订地点：
连接协议tcp篇二
前段时间做了一个开发，涉及到网络编程，开发过程比较顺利，但任务完成后始终觉得有一些疑惑。主要是因为对网络协议不太熟悉，对一些概念也没弄清楚。后来 我花了一些时间去了解这些网络协议，现在对tcp/ip网络协议有了初步的认识，在这里总结出来，可以梳理一下我对网络协议的理解，加深印象。
话说两台电脑要通讯就必须遵守共同的规则，就好比两个人要沟通就必须使用共同的语言一样。一个只懂英语的人，和一个只懂中文的人由于没有共同的语言(规则)就没办法沟通。两台电脑之间进行通讯所共同遵守的规则，就是网络协议。
国际标准化组织(iso)定义了网络协议的基本框架，被称为osi模型。要制定通讯规则，内容会很多，比如要考虑a电脑如何找到b电脑，a电脑在发送信息 给b电脑时是否需要b电脑进行反馈，a电脑传送给b电脑的数据的格式又是怎样的?内容太多太杂，所以osi模型将这些通讯标准进行层次划分，每一层次解决 一个类别的问题，这样就使得标准的制定没那么复杂。osi模型制定的七层标准模型，分别是：应用层，表示层，会话层，传输层，网络层，数据链路层，物理 层。
虽然国际标准化组织制定了这样一个网络协议的模型，但是实际上互联网通讯使用的网络协议是tcp/ip网络协议。
tcp/ip 是一个协议族，也是按照层次划分。共四层：应用层，传输层，互连网络层，网络接口层。 那么tcp/ip协议和osi模型有什么区别呢?osi网络协议模型，是一个参考模型，而tcp/ip协议是事实上的标准。tcp/ip协议参考了osi 模型，但是并没有严格按照osi规定的七层去划分标准，而只划分了四层，个人觉得这样会更简单点，当划分太多层次时，你很难区分某个协议是属于哪个层次 的。tcp/ip协议和osi模型也并不冲突，tcp/ip协议中的应用层协议，就对应于osi中的应用层，表示层，会话层。就像以前有工业部和信息产业 部，现在实行大部制后只有工业和信息化部一个部门，但是这个部门还是要做以前两个部门一样多的事情，本质上没有多大的差别。tcp/ip中有两个重要的协 议，传输层的tcp协议和互连网络层的ip协议，因此就拿这两个协议做代表，来命名整个协议族了，在说tcp/ip协议时，是指整个协议族。
tcp/ip协议分为四个层次，但我们并不需要了解所有层次的协议，我觉得主要关注应用层和传输层的`协议就可以了。拿寄送邮件举例， a寄邮件给b，a关心的是用什么格式写什么内容给b(应用层内容)，是寄挂号信还是寄平信(传输层内容)，但是a是不会去关注邮件传送过程中采用了那条路 线，邮递员是如何把信件递送到b手里的(互连网络层，网络接口层)。
先说传输层，传输层有多个协议，但最主要的是tcp和udp协议。两则的区别在于tcp协议需要接收方反馈，udp协议不需要接收方反馈。tcp就像挂号 信，a电脑发信息给b电脑后，需要得到b电脑的反馈，这样a电脑就能知道b电脑是否已经收到信息。udp就像平信，a电脑发信息给b电脑后，b电脑并不给 a电脑发聩，a电脑发送信息出去后并不知道b电脑是否已经收到。 因此，tcp传输比udp传送更可靠，但是tcp传输的效率就不如udp了。至于，在传送过程中具体选择哪种传送方式，需要具体问题具体分析。在不可靠的 网络传送过程中一般选择tcp传送方式。在讲求效率，或者不在乎传送失误的情况下可以选择udp方式来提高传输速率。
应用层的协议有很多，每一个协议代表一种类型的服务。http协议，万维网服务。ftp协议，文件传送服务。pop3，邮件服务，soap协议webservice服务。
在理解tcp/ip协议的过程中，我遇到了三个困惑。
我现在的理解是，socket就是一个连接中的一个端点，一次通讯(连接)a,b端都会有一个socket。一个socket对应一个连接。
http中文译名问题
http 在中国大陆被翻译为“超文本传输协议”，因为“transfer”在中文里有“传输”的含意。但依据 http 定制者之一的 roy fielding博士的论文[1](6.5.3节)，作者专门强调“transfer”表示的是“(表述状态的)转移” (representational state transfer)，而不是“传输”(transport)。故其中文译名“超文本传输协议”恰恰引种反映了这种误解。更符合原义的译名应该为“超文本转 移协议”。
这段话解除了我的疑惑。那么http协议当然是应用层的协议。
在了解soap协议的过程中，看到介绍说soap可以通过tcp,udp,http协议来传送。这也是让人困惑的描述。一看这句话，就会感觉http怎么 和tcp,udp协议并列了呢?难道http还是属于传输层的协议?再加上http中文译名的问题，名字听上去像传输层，初学者又要开始头大了。
我查阅了资料，是这样一回事情，soap将信息进行xml的序列化后，再用http协议的方式再打包进行传送，传送的方式还是tcp或者udp。做个比喻 就好理解了。tcp 和 udp 都是公路，暂且把tcp认为是一般公路，udp高速公路，soap和http就都是汽车，那么soap和http都可以在tcp和udp上跑。说soap 可以通过http来传送，实际就是说soap是小轿车，http是装轿车的卡车，把soap的信息装到http里面，然后再运输，当然走的道路还是tcp 或udp。
说soap可以通过http协议来传输，这句话不太准确，比较准确第说法是：soap信息可以通过http协议包装后通过tcp或udp传输。
连接协议tcp篇三
;摘要： 目前tcp/ip已经成为网络的主导技术。通过对tcp底层实现的分析，对tcp/ip编程中一个长期使人困惑的问题——网络连接中断的实时检测进行深入的分析，并提出相应的解决方案。
关键词： 网络编程；tcp/ip；实时监测
0 引言
作为现代网络的主导技术，tcp/ip编程看起来非常简单，但在经历了最初的高效率后，往往会在细节面前停滞不前，这常常是因为对tcp协议底层细节的缺乏了解所导致的。
tcp是面向连接协议，而udp是无连接协议，许多初学者发现可以没有任何数据流通过一个空闲的tcp连接，如果tcp连接的双方都没有向对方发送数据，则在两个tcp模块之间不交换任何信息。这意味着可以启动一个客户与服务器建立一个连接，然后离去数小时至数个星期连接依然保持。中间路由器可以崩溃和重启，电话线可以被挂断再连通，只要两端的主机没有被重启，则连接依然保持建立。
1 原理分析
tcp通常被称为可靠的协议，即“tcp保证发送数据的传输”，这通常会产生误解：tcp不会出错。事实是只要双方保持连接，tcp就能保证数据的正确传输，但是当连接中断时，就会产生问题，原因有3个：1）永久的或暂时的网络紊乱；2）对等方应用程序崩溃；3）对等方主机崩溃，当出现以上问题时，会使双方应用程序不能互相通信，而其中一个应用程序却不能立刻意识到。发送数据给对等方的应用程序可能在知道tcp在放弃重发之前才会发现连接中断，如果应用程序没有发送数据，可能永远不会发现网络已经中断。例如应用程序可能是一个正在等待对等方发出下一个请求的服务器，因为客户端不能和服务器通信，下一个请求永远不会到达，甚至客户端的tcp放弃并撤销连接，导致客户端中断，服务器也没有意识到这一点。
其他的通信协议如sna和x.25，当连接中断时会给应用程序提供通知。比如简单的直接点对点专有链接复杂的任何协议都必须使用一种轮询协议来连续地测试对等方是否存在。轮询-选择协议可能会采用显式地发送“你有要发送给我的任何数据吗?”诸如此类的消息的形式，或者它们会采用后台静态帧的形式来检测虚拟线路是否仍然存在。每一个轮询消息都会消耗网络资源，而这些资源本来可以用于“有效负载”数据的传输。
对可获得的网络带宽的消耗是tcp不提供网络中断立即通知的一个原因。因为大多数的应用程序不需要即时的通知，所以没有必要以降低带宽的代价来提供这个功能。需要以一种及时的方式知道对等方不可到达的应用程序可以实现它们自己的机制来发现网络中断，如后面介绍的那样。
tcp/ip设计中使用的一个基本原则是终端对终端参数[saltzer el al.1984]，该参数应用到网络上时可以表述为所有的智能应当尽可能地接近连接的终端点，而网络本身应当相对没有智能。这就是为什么tcp自己处理错误控制而不是依靠网络来提供它的原因。当这个原则应用到监控对等应用程序之间的连接时，应用程序应当提供它自己需要的功能，而不是不管应用程序是否需要这个功能都由下层提供。
tcp不提供及时连接中断通知的最重要的原因是：网络突然中断时仍可以维持通讯的能力。tcp最早是美国国防部发起的一项研究的成果，它要求提供一个遇到战争或自然灾害引起的网络中断时仍然可以维持计算机之间可靠的通信的网络协议。通常网络紊乱是暂时的，路由器也可能找到连接的另一条路径。通过允许连接的暂时中断，甚至在终端应用程序意识到中断之前tcp就已经处理好了紊乱。
2 解决方案
2.1 方案一：使用tcp keep-alive机制
人们希望知道连接是否中断了，因此许多tcp的具体实现提供了一个称作keep-alive的机制用于检测死连接，但是它并不经常用于应用程序。如果应用程序启用keep-alive机制时，tcp就会在连接已经空闲了一段时间间隔后发送一个特殊的段给对等方。如果对等方主机可到达而且对等方应用程序仍然运行，对等方tcp就会响应一个ack应答。在这种情况下，tcp发送keep-alive重置空闲时间为零，并且应用程序不会收到消息交换的任何通知。
如果对等方主机可以到达但是对等方应用程序没有运行，对等方tcp就响应rst消息，发送keep-alive消息的tcp撤销连接并返回econnreset错误给应用程序。这通常是对等方主机崩溃后重起的结果，因为如果仅仅是对等方应用程序中断或崩溃了，对等方tcp可能已经发送fin消息了。
如果对等方主机没有响应ack或rst消息，发送keep-alive消息的tcp继续发送keep-alive探询消息，直到它认为对等方不可到达或已经崩溃了。这时它就撤销连接并通知应用程序etimedout错误，如果路由器已经返回主机或网络不可到底的icmp消息的话，就返回ehostunreach或enerunreach错误。
通过keep-alive机制，tcp提供了协议层面的网络中断通知功能，但这种机制有很多问题以至于很少用于应用程序。
首先，keep-alive并不是tcp规范中的一部分，长期以来，是否在tcp中提供keep-alive机制一直是有争论的话题，因此，keep-alive不是所有的tcp实现都提供，而且实现细节也有所不同。
需要即时通知网络中断的应用程序使用keep-alive功能的第二个问题是和时间间隔有关的。rfc 1122[braden 1989]认为，如果tcp实现了keep-alive，保活间隔必须是可配置的，但是其默认值必须不小于两个小时，之后它才能发送 keep-alive探询消息。那么因为对等方的ack消息并不是可靠地递交，它必须在放弃连接之前重复发送探询消息。4.4bsd具体实现在撤销连接之前以75秒的时间间隔发送9个探询消息。
这意味着bsd派生的具体实现，大约需要2小时11分钟15秒才能发现连接已经中断了。这个时间值只有在我们认识keep-alive是用于释放被死连接占有的资源时才有意义。例如，当客户端连接到服务器而客户端主机崩溃时就有可能发生这样的连接。如果没有keep-alive机制，服务器就会永远等待客户端的下一个请求，这是因为它永远没有接收到fin消息。（因为基于pc系统的用户仅仅是关闭计算机和modem而不是正确地关闭应用程序，所以这种情况正越来越普遍。）
由于2小时的时间对于实时检测几乎没有意义，因此一些具体实现允许改变一个或两个时间间隔值，但因为保活间隔时间是系统级的变量，这些值的改变影响系统上所有的tcp连接，这是keep-alive作为一个连接监控机制没有实际使用的主要原因：默认的时间段太长了，如果改变了默认值，它们就失去了清除长时间死连接这一最初的意义。
keep-alive的另一个问题是它们不仅仅检测死连接，同时也撤销它们。这有可能是应用程序所希望的，但是也有可能不是应用程序所希望的。
2.2 方案二：使用heartbeat检测
第二种方案是在应用层来实现对连接中断的检测，其基本思想是象keep-alive一样，定时向对等方发送探针，由于是在应用层实现，可以根据应用程序灵活掌握探测时间。实际上，边界网关协议bgp就是通过定期发送keep-alive报文给其邻站来检测tcp连接对端的链路或主机失败，两个报文之间的时间间隔建议值为30秒。这种在应用层实现的对连接中断的检测通常称为“heartbeat检测”。
以上算法原则尽管是在tcp上讨论，但一样适用于udp。这种方案的最大优点在于提供了最大的灵活性。
2.3 方案三：利用tcp-keepalive套接字选项
#ifdef tcp_keepalive
int secs = 120; /* 2 minutes */
#endif
这种方案的缺点是，由于tcp-keepalive套接字选项是比较新的posix特性，不是所有tcp实现都给予支持，因此存在移植性问题；同时，由于是在传输层进行探测，灵活性不如在应用层的实现。
3 总结
综上所述，对于tcp连接中断的检测，原理上都是通过定时向对等方发送探针数据来进行检测，不同方案的区别在于实现于不同层次，应用中可以根据需要进行不同的选择，关键在于对tcp连接的原理要透彻理解。
相关热词搜索：;连接协议tcp篇四
tcp和udp处在同一层---运输层，但是tcp和udp最不同的地方是，tcp提供了一种可靠的数据传输服务，tcp是面向连接的，也就是说，利用tcp通信的两台主机首先要经历一个“拨打电话”的过程，等到通信准备结束才开始传输数据，最后结束通话。所以tcp要比udp可靠的多，udp是把数据直接发出去，而不管对方是不是在收信，就算是udp无法送达，也不会产生icmp差错报文，这一经时重申了很多遍了。
tcp将保持它首部和数据的检验和。这是一个端到端的检验和，目的是检测数据在传输 过程中的任何变化。如果收到段的检验和有差错， t p将丢弃这个报文段和不确认收到此报文段(希望发端超时并重发)。
既然tcp报文段作为ip数据报来传输，而ip数据报的到达可能会失序，因此tcp报文段 的到达也可能会失序。如果必要， tcp将对收到的数据进行重新排序，将收到的数据以正确的顺序交给应用层。
tcp还能提供流量控制。tcp连接的每一方都有固定大小的缓冲空间。tcp的接收端只允许另一端发送接收端缓冲区所能接纳的数据。这将防止较快主机致使较慢主机的缓冲区溢出。
从这段话中可以看到，tcp中保持可靠性的方式就是超时重发，这是有道理的，虽然tcp也可以用各种各样的icmp报文来处理这些，但是这也不是可靠的，最可靠的方式就是只要不得到确认，就重新发送数据报，直到得到对方的确认为止。
tcp的首部和udp首部一样，都有发送端口号和接收端口号。但是显然，tcp的.首部信息要比udp的多，可以看到，tcp协议提供了发送和确认所需要的所有必要的信息。可以想象一个tcp数据的发送应该是如下的一个过程。
发送方给接受方tcp数据报，然后等待对方的确认tcp数据报，如果没有，就重新发，如果有，就发送下一个数据报。
接受方等待发送方的数据报，如果得到数据报并检验无误，就发送ack(确认)数据报，并等待下一个tcp数据报的到来。直到接收到fin(发送完成数据报)
--
tcp是一个面向连接的协议，在发送输送之前 ，双方需要确定连接。而且，发送的数据可以进行tcp层的分片处理。
tcp连接的建立过程 ，可以看成是三次握手 。而连接的中断可以看成四次握手 。
1.连接的建立
在建立连接的时候，客户端首先向服务器申请打开某一个端口(用syn段等于1的tcp报文)，然后服务器端发回一个ack报文通知客户端请求报文收到，客户端收到确认报文以后再次发出确认报文确认刚才服务器端发出的确认报文(绕口么)，至此，连接的建立完成。这就叫做三次握手。如果打算让双方都做好准备的话，一定要发送三次报文，而且只需要三次报文就可以了。
可以想见，如果再加上tcp的超时重传机制，那么tcp就完全可以保证一个数据包被送到目的地。
2.结束连接
tcp有一个特别的概念叫做half-close，这个概念是说，tcp的连接是全双工(可以同时发送和接收)连接，因此在关闭连接的时候，必须关闭传和送两个方向上的连接。客户机给服务器一个fin为1的tcp报文，然后服务器返回给客户端一个确认ack报文，并且发送一个fin报文，当客户机回复ack报文后(四次握手)，连接就结束了。
3.最大报文长度
在建立连接的时候，通信的双方要互相确认对方的最大报文长度(mss)，以便通信。一般这个syn长度是mtu减去固定ip首部和tcp首部长度。对于一个以太网，一般可以达到1460字节。当然如果对于非本地的ip，这个mss可能就只有536字节，而且，如果中间的传输网络的mss更加的小的话，这个值还会变得更小。
4.客户端应用程序的状态迁移图
客户端的状态可以用如下的流程来表示：
以上流程是在程序正常的情况下应该有的流程，从书中的图中可以看到，在建立连接时，当客户端收到syn报文的ack以后，客户端就打开了数据交互地连接。而结束连接则通常是客户端主动结束的，客户端结束应用程序以后，需要经历fin_wait_1，fin_wait_2等状态，这些状态的迁移就是前面提到的结束连接的四次握手。
5.服务器的状态迁移图
服务器的状态可以用如下的流程来表示：
在建立连接的时候，服务器端是在第三次握手之后才进入数据交互状态，而关闭连接则是在关闭连接的第二次握手以后(注意不是第四次)。而关闭以后还要等待客户端给出最后的ack包才能进入初始的状态。
服务器设计
前面曾经讲述过udp的服务器设计，可以发现udp的服务器完全不需要所谓的并发机制，它只要建立一个数据输入队列就可以。但是tcp不同，tcp服务器对于每一个连接都需要建立一个独立的进程(或者是轻量级的，线程)，来保证对话的独立性。所以tcp服务器是并发的。而且tcp还需要配备一个呼入连接请求队列(udp服务器也同样不需要)，来为每一个连接请求建立对话进程，这也就是为什么各种tcp服务器都有一个最大连接数的原因。而根据源主机的ip和端口号码，服务器可以很轻松的区别出不同的会话，来进行数据的分发。
对于交互性要求比较高的应用，tcp给出两个策略来提高发送效率和减低网络负担：(1)捎带ack。(2)nagle算法(一次尽量多的发数据)
这个策略是说，当主机收到远程主机的tcp数据报之后，通常不马上发送ack数据报，而是等上一个短暂的时间，如果这段时间里面主机还有发送到远程主机的tcp数据报，那么就把这个ack数据报“捎带”着发送出去，把本来两个tcp数据报整合成一个发送。一般的，这个时间是200ms。可以明显地看到这个策略可以把tcp数据报的利用率提高很多。
上过bbs的人应该都会有感受，就是在网络慢的时候发贴，有时键入一串字符串以后，经过一段时间，客户端“发疯”一样突然回显出很多内容，就好像数据一下子传过来了一样，这就是nagle算法的作用。
nagle算法是说，当主机a给主机b发送了一个tcp数据报并进入等待主机b的ack数据报的状态时，tcp的输出缓冲区里面只能有一个tcp数据报，并且，这个数据报不断地收集后来的数据，整合成一个大的数据报，等到b主机的ack包一到，就把这些数据“一股脑”的发送出去。虽然这样的描述有些不准确，但还算形象和易于理解，我们同样可以体会到这个策略对于低减网络负担的好处。
在编写插口程序的时候，可以通过tcp_nodelay来关闭这个算法。并且，使用这个算法看情况的，比如基于tcp的x窗口协议，如果处理鼠标事件时还是用这个算法，那么“延迟”可就非常大了。
