本篇博文其实并不只是学习三握手四挥手，而是总结计网传输层的内容，只是这八个字在传输层中地位实在太重了…故单列出来做标题，当然，你耳熟能详的滑动窗口这里也会涉及到 传输层之下的层之前也已经写了…推荐你阅读 计算机网络-网络层-详细总结 在TCP/IP协议栈，传输层有两个协议TCP和UDP TCP（Transmission Control Protocol，传输控制协议）协议：负责将要传输的文件分段 进行传输，一般用于建立会话 ，其基本特性是可靠传输 、流量控制，所谓三握手、四挥手也是基于TCP协议的 UDP（User Data Protocol，用户数据报协议）协议：一个数据包就能够完成数据通信 ，数据包不分段 ，不需要建立会话 ，不需要流量控制 ，属于不可靠传输 ， 屏幕广播 、多播 、广播都是基于UDP协议 以上定义，下面来详讲 TCP和UDP协议内指定不同的端口即可对应一个应用层的协议 端口代表主机服务的侦听”门牌号”，不管是TCP还是UDP，带上门牌号，它就能帮你找到主机上的对应服务 例如我们在浏览器访问某个网站地址，这个动作会被我们本机上的80端口侦听到，并处理你的网络请求 我们主机上常见的应用层协议端口： 但是我们通过TCP/UDP封装的数据包，通过本机侦听服务发送到目标主机，目标主机是如何识别并处理的呢？ 如上图，我们会在数据包中添加目标端口号，这样目标主机相关服务侦听到，就能处理我们的请求了 说白了，IP协议主要让数据能知道传到哪去，不管对应目标谁来负责接待，而TCP/UDP管 越靠近顶层应用层、功能越强大 主要特点： 基本描述： UDP首部 首先得知道数据包在OSI模型中层层传输，自顶向下 来看看UDP首部 基本特点： TCP 是面向连接的传输层协议，UDP面向无连接 每一条 TCP 连接只能有两个端点(endpoint)，每一条 TCP 连接只能是点对点的（一对一） TCP 提供可靠交付的服务（持续交付） TCP 提供全双工通信（信道双向传输） 面向字节流(传送最小单位为字节，即八位) 上图可以看出TCP传输是如何面向字节流的，具体细节后面继续解析 TCP连接基于Socket： TCP 把连接作为最基本的抽象，每一条 TCP 连接有两个端点 TCP 连接的端点不是主机，不是主机的IP 地址，不是应用进程，也不是传输层的协议端口。TCP 连接的端点叫做套接字(socket) IP地址+服务端口构成了套接字 TCP使用自动重传请求ARQ (Automatic Repeat reQuest)确保可靠传输 停止等待机制: 报文过不了检验的，被B丢弃，A发送发出去的报文无回应、重新发送 请注意： 确认丢失和确认迟到机制： 使用上述的确认和重传机制，我们就可以在不可靠的传输网络上实现可靠的通信。 ARQ 表明重传的请求是自动进行的 TCP流水线传输： 停止等待协议的优点是简单，但缺点是信道利用率太低 改进: 发送方可连续发送多个分组，不必每发完一个分组就停顿下来等待对方的确认，由于信道上一直有数据不间断地传送，这种传输方式可获得很高的信道利用率 连续 ARQ 协议(自动重传协议): 连续ARQ（Automatic Repeat reQuest）协议指发送方维持着一个一定大小的发送窗口，位于发送窗口内的所有分组都可连续发送出去，而中途不需要等待对方的确认。这样信道的利用率就提高了。而发送方每收到一个确认就把发送窗口向前滑动一个分组的位置 接收方一般都是采用积累确认的方式。这就是说，接收方不必对收到的分组逐个发送确认，而是在收到几个分组后，对按序到达的最后一个分组发送确认，这就表示：到这个分组为止的所有分组都已正确收到了 积累确认有优点也有缺点。优点是：容易实现，即使确认丢失也不必重传。但缺点是不能向发送方反映出接收方已经正确收到的所有分组的信息 例如，如果发送方发送了前5个分组，而中间的第3个分组丢失了。这时接收方只是对前两个分组发出确认。发送方无法知道后面三个分组的下落，而只好把后面的三个分组都再重传一次。这就叫做Go-back-N（回退N），表示需要再退回来重传已发送过的N个分组。可见当通信线路质量不好时，连续ARQ协议会带来负面的影响 TCP 报文段的首部格式: TCP 可靠通信的具体实现： 窗口动态变化-以字节为单位的滑动窗口： 相关名词： P3 – P1 = A 的发送窗口（又称为通知窗口） 流量控制(flow control)就是让发送方的发送速率不要太快，既要让接收方来得及接收，也不要使网络发生拥塞 利用滑动窗口机制可以很方便地在 TCP 连接上实现流量控制，收方返回的 rwnd中会包含自己的接收窗口的大小，并且利用大小来控制发送方的数据发送，发送方在rwnd窗口之后的数据不允许发送 流量控制根本目的是防止分组丢失，它是构成TCP可靠性的一方面 死锁解决： 接收方返回窗口大小为0，可能是缓冲区已满，需要处理缓存中的字节，发送端收到滑动窗口为0，不再发送，但是数据还没发送完，这就造成了死锁 如果在某个时候，接收方缓冲区有空间了，于是发送了一个非 0 窗口的通告给接收方，不幸的是这个通告丢失了，而发送方却还在死等接收方的非 0 窗口通告，接下来就成了死锁 TCP 为每一个连接设有一个持续计时器 若持续计时器设置的时间到期，就周期性的向接收方发送 1 字节的 0 窗口探测报文 若窗口仍然是零，则收到这个报文段的一方就重新设置持续计时器，等待重传 若窗口不是零，则死锁的僵局就可以打破了 传输连接有三个阶段，即：连接建立（三次握手）、数据传送和连接释放（四次挥手） 头两次握手除了确定双方都能联通外，还通知了双方的一些端口信息 A：我们谈恋爱吧 B：好的（如果“好的“丢了，A就不知道B的态度，感情就无法建立起来） C：走你~ 第三次握手原因：假如把三次握手改成仅需要两次握手，死锁是可能发生的。作为例子，考虑计算机A和B之间的通信，假定A给B发送一个连接请求分组，B收到了这个分组，并发送了确认应答分组。按照两次握手的协定，B认为连接已经成功地建立了，可以开始发送数据分组。可是，B的应答分组在传输中被丢失的情况下，A将不知道B是否已准备好，A认为连接还未建立成功，将忽略B发来的任何数据分组，这样就形成了死锁 A 的应用进程先向其 TCP 发出连接释放报文段，并停止再发送数据，主动关闭 TCP A 把连接释放报文段首部的 FIN = 1，其序号seq = u，等待 B 的确认（A：分手吧？） B 发出确认，确认号 ack = u + 1，而这个报文段自己的序号 seq = v（B：确定吗？） TCP 服务器进程通知高层应用要进行关闭了 从 A 到 B 这个方向的连接就释放了，TCP 连接处于半关闭状态。B 若发送数据，A 仍要接收（因为A要知道B是否收到断开请求） 若 B 已经没有要向 A 发送的数据，其应用进程就通知 TCP 释放连接，并通知A连接已关闭（B:那就分了吧，我走了） A 收到连接释放报文段后，必须发出确认(好的)
三次握手齐白首，四次挥手说分手
说起来TCP的连接与释放真是个浪漫的故事呢！~
文章目录
TCP/IP协议概述
传输层协议的作用体现在应用层协议
TCP/UDP传输层协议与网络层协议的区别
UDP协议
TCP协议
TCP协议确保可靠传输
滑动窗口
P2 – P1 = 已发送但尚未收到确认的字节数
P3 – P2 = 允许发送但尚未发送的字节数（又称为可用窗口
TCP流量控制
三次握手齐白首
四次挥手说分手
连接
本网页所有视频内容由 imoviebox边看边下-网页视频下载, iurlBox网页地址收藏管理器 下载并得到。
ImovieBox网页视频下载器 下载地址: ImovieBox网页视频下载器-最新版本下载
本文章由: imapbox邮箱云存储,邮箱网盘,ImageBox 图片批量下载器,网页图片批量下载专家,网页图片批量下载器,获取到文章图片,imoviebox网页视频批量下载器,下载视频内容,为您提供.
阅读和此文章类似的: 全球云计算
官方软件产品操作指南 (170)
