原文链接:blog.csdn.net

用这个媒体播放器组件,实时互动时也可共同观看本地视频juejin.im

前言

  • 计算机网络基础 该是程序猿需掌握的知识,但往往会被忽略
  • 今天,我将详细讲解计算机网络中最重要的TCP协议,含其特点、三次握手、四次挥手、无差错传输等知识,希望你们会喜欢。

阅读本文前,请先了解计算机网络基础知识:献上一份全面 & 详细的计算机网络基础 学习指南


目录


1. 定义

Transmission Control Protocol,即 传输控制协议

  1. 属于 传输层通信协议
  2. 基于TCP的应用层协议有HTTPSMTPFTPTelnet 和 POP3

2 特点

  • 面向连接、面向字节流、全双工通信、可靠
  • 具体介绍如下:


3. 优缺点

  • 优点:数据传输可靠
  • 缺点:效率慢(因需建立连接、发送确认包等)

4. 应用场景(对应的应用层协议)

要求通信数据可靠时,即 数据要准确无误地传递给对方

如:传输文件:HTTP、HTTPS、FTP等协议;传输邮件:POP、SMTP等协议

  • 万维网:HTTP协议
  • 文件传输:FTP协议
  • 电子邮件:SMTP协议
  • 远程终端接入:TELNET协议

5. 报文段格式

  • TCP虽面向字节流,但传送的数据单元 = 报文段
  • 报文段 = 首部 + 数据 2部分
  • TCP的全部功能体现在它首部中各字段的作用,故下面主要讲解TCP报文段的首部
  1. 首部前20个字符固定、后面有4n个字节是根据需而增加的选项
  2. 故 TCP首部最小长度 = 20字节


6. 建立连接过程

  • TCP建立连接需 三次握手
  • 具体介绍如下

成功进行TCP的三次握手后,就建立起一条TCP连接,即可传送应用层数据

  1. 因 TCP提供的是全双工通信,故通信双方的应用进程在任何时候都能发送数据
  2. 三次握手期间,任何1次未收到对面的回复,则都会重发

特别说明:为什么TCP建立连接需三次握手?

  • 结论
    防止服务器端因接收了早已失效的连接请求报文,从而一直等待客户端请求,最终导致形成死锁、浪费资源

  • 具体描述

SYN洪泛攻击:

  • 从上可看出:服务端的TCP资源分配时刻 = 完成第二次握手时;而客户端的TCP资源分配时刻 = 完成第三次握手时
  • 这就使得服务器易于受到SYN洪泛攻击,即同时多个客户端发起连接请求,从而需进行多个请求的TCP连接资源分配

7. 释放连接过程

  • 在通信结束后,双方都可以释放连接,共需 四次挥手
  • 具体如下

特别说明:为什么TCP释放连接需四次挥手?

  • 结论
    为了保证通信双方都能通知对方 需释放 & 断开连接

即释放连接后,都无法接收 / 发送消息给对方

  • 具体描述

延伸疑问:为什么客户端关闭连接前要等待2MSL时间?

  1. 即 TIME - WAIT 状态的作用是什么;
  2. MSL = 最长报文段寿命(Maximum Segment Lifetime
  • 原因1:为了保证客户端发送的最后1个连接释放确认报文 能到达服务器,从而使得服务器能正常释放连接

  • 原因2:防止 上文提到的早已失效的连接请求报文 出现在本连接中
    客户端发送了最后1个连接释放请求确认报文后,再经过2MSL时间,则可使本连接持续时间内所产生的所有报文段都从网络中消失。

即 在下1个新的连接中就不会出现早已失效的连接请求报文


8. 无差错传输

  • 对比于UDPTCP的传输是可靠的、无差错的
  • 那么,为什么TCP的传输为什么是可靠的、无差错的呢?
  • 下面,我将详细讲解TCP协议的无差错传输

8.1 含义

  • 无差错:即 传输信道不出差错
  • 发送 & 接收效率匹配:即 无论发送方以多快的速度发送数据,接收方总来得及处理收到的数据

8.2 基础:滑动窗口 协议

  • 先理解2个基础概念:发送窗口、接收窗口

  • 工作原理
    对于发送端:
  1. 每收到一个确认帧,发送窗口就向前滑动一个帧的距离
  2. 当发送窗口内无可发送的帧时(即窗口内的帧全部是已发送但未收到确认的帧),发送方就会停止发送,直到收到接收方发送的确认帧使窗口移动,窗口内有可以发送的帧,之后才开始继续发送
    具体如下图:

对于接收端:当收到数据帧后,将窗口向前移动一个位置,并发回确认帧,若收到的数据帧落在接收窗口之外,则一律丢弃。

滑动窗口 协议的重要特性

  • 只有接收窗口向前滑动、接收方发送了确认帧时,发送窗口才有可能(只有发送方收到确认帧才是一定)向前滑动
  • 停止-等待协议、后退N帧协议 & 选择重传协议只是在发送窗口大小和接收窗口大小上有所差别:
  1. 停止等待协议:发送窗口大小=1,接收窗口大小=1;即 单帧滑动窗口 等于 停止-等待协议
  2. 后退N帧协议:发送窗口大小>1,接收窗口大小=1。
  3. 选择重传协议:发送窗口大小>1,接收窗口大小>1。
  • 当接收窗口的大小为1时,可保证帧有序接收。
  • 数据链路层的滑动窗口协议中,窗口的大小在传输过程中是固定的(注意要与TCP的滑动窗口协议区别)

8.3 实现无差错传输的解决方案

核心思想:采用一些可靠传输协议,使得

  1. 出现差错时,让发送方重传差错数据:即 出错重传
  2. 当接收方来不及接收收到的数据时,可通知发送方降低发送数据的效率:即 速度匹配
  • 针对上述2个问题,分别采用的解决方案是:自动重传协议 和 流量控制 & 拥塞控制协议

解决方案1:自动重传请求协议ARQ(针对 出错重传)

  • 定义
    即 Auto Repeat reQuest,具体介绍如下:

  • 类型

下面,将主要讲解 上述3类协议

类型1:停等式ARQ(Stop-and-Wait)

  • 原理:(单帧滑动窗口)停止 - 等待协议 + 超时重传

即 :发送窗口大小=1、接收窗口大小=1

  • 停止 - 等待协议的协议原理如下:
  1. 发送方每发送一帧,要等到接收方的应答信号后才能发送下一帧
  2. 接收方每接收一帧,都要反馈一个应答信号,表示可接下一帧
  3. 若接收方不反馈应答信号,则发送方必须一直等待

类型2:后退N帧协议

也称:连续ARQ协议

  • 原理
    多帧滑动窗口 + 累计确认 + 后退N帧 + 超时重传

即 :发送窗口大小>1、接收窗口大小=1

  • 具体描述
    a. 发送方:采用多帧滑动窗口的原理,可连续发送多个数据帧 而不需等待对方确认
    b. 接收方:采用 累计确认 & 后退N帧的原理,只允许按顺序接收帧。具体原理如下:

示例讲解

本示例 = 源站 向 目的站 发送数据帧。具体示例如下:

类型3:选择重传ARQ(Selective Repeat)

  • 原理
    多帧滑动窗口 + 累计确认 + 后退N帧 + 超时重传

即 :发送窗口大小>1、接收窗口大小>1

类似于类型2(后退N帧协议),此处仅仅是接收窗口大小的区别,故此处不作过多描述

  • 特点
    a. 优:因连续发送数据帧而提高了信道的利用率
    b. 缺:重传时又必须把原来已经传送正确的数据帧进行重传(仅因为这些数据帧前面有一个数据帧出了错),将导致传送效率降低

由此可见,若信道传输质量很差,导致误码率较大时,后退N帧协议不一定优于停止-等待协议

解决方案2:流量控制 & 拥塞控制(针对 速度匹配)

措施1:流量控制

  • 简介

  • 示例

  • 特别注意:死锁问题


措施2:拥塞控制

  • 定义
    防止过多的数据注入到网络中,使得网络中的路由器 & 链路不致于过载

拥塞:对网络中的资源需求 > 该资源所能提供的部分

  • 与 “流量控制”的区别

  • 具体解决方案
    共分为2个解决方案:慢开始 & 拥塞避免、快重传 & 快恢复

其中,涉及4种算法,即 慢开始 & 拥塞避免、快重传 & 快恢复

具体介绍如下

解决方案1:慢开始 & 拥塞避免

1.1 储备知识:拥塞窗口、慢开始算法、拥塞避免算法

a. 拥塞窗口

  • 发送方维持一个状态变量:拥塞窗口(cwnd, congestion window ),具体介绍如下

b. 慢开始算法

  • 原理 当主机开始发送数据时,由小到大逐渐增大 拥塞窗口数值(即 发送窗口数值),从而 由小到大逐渐增大发送报文段

  • 目的
    开始传输时,试探网络的拥塞情况

  • 具体措施

  • 示意图

  • 特别注意
    慢开始的“慢”指:一开始发送报文段时拥塞窗口(cwnd)设置得较小(为1),使得发送方在开始时只发送一个报文段(目的是试探一下网络的拥塞情况)

并不是指拥塞窗口(cwnd)的增长速率慢

c. 拥塞避免 算法

  • 原理
    使得拥塞窗口(cwnd)按线性规律 缓慢增长:每经过一个往返时间RTT,发送方的拥塞窗口(cwnd)加1
  1. 拥塞避免 并不可避免拥塞,只是将拥塞窗口按现行规律缓慢增长,使得网络比较不容易出现拥塞
  2. 相比慢开始算法的加倍,拥塞窗口增长速率缓慢得多
  • 示意图

1.2 解决方案描述(慢开始 & 拥塞避免)

  • 为了防止拥塞窗口(cwnd)增长过大而引起网络拥塞,采用慢开始 & 拥塞避免 2种算法,具体规则如下

  • 实例说明

解决方案2:快重传 & 快恢复

快重传 & 快恢复的解决方案 是对慢开始 & 拥塞避免算法的改进

2.1 储备知识:快重传算法、快恢复算法

a. 快重传算法

  • 原理

    1. 接收方 每收到一个失序的报文段后 就立即发出重复确认(为的是使发送方及早知道有报文段没有到达对方),而不要等到自己发送数据时才进行捎带确认
    2. 发送方只要一连收到3个重复确认就立即重传对方尚未收到的报文段,而不必 继续等待设置的重传计时器到期
  • 作用 由于发送方尽早重传未被确认的报文段,因此采用快重传后可以使整个网络吞吐量提高约20%

  • 示意图

b. 快恢复

当发送方连续收到3个重复确认后,就:

  1. 执行 乘法减小 算法:把 慢开始门限(ssthresh)设置为 出现拥塞时发送方窗口值的一半 = 拥塞窗口的1半
  2. 将拥塞窗口(cwnd)值设置为 慢开始门限ssthresh减半后的数值 = 拥塞窗口的1半
  3. 执行 加法增大 算法:执行拥塞避免算法,使拥塞窗口缓慢地线性增大。

注:

  1. 由于跳过了拥塞窗口(cwnd)从1起始的慢开始过程,所以称为:快恢复
  2. 此处网络不会发生网络拥塞,因若拥塞,则不会收到多个重复确认报文

2.2 解决方案描述(快重传 & 快恢复)

  • 原理
    为了优化慢开始 & 拥塞避免的解决方案,在上述方案中加入快重传 & 快恢复 2种算法,具体规则如下

  • 示意图

至此,关于TCP无差错传输的知识讲解完毕。


9. 与UDP协议的区别


10. 总结

  • 本文全面讲解了 计算机网络中最重要的TCP协议,含其特点、三次握手、四次挥手、无差错传输等知识,相信你们对TCP协议已经非常了解

  • 下面我将继续讲解 编程开发的基础知识,有兴趣可以继续关注Carson_Ho的开发笔记

计算机网络:这是一份全面 & 详细 的TCP协议学习指南的更多相关文章

  1. 这是一份很详细的 Retrofit 2.0 使用教程(含实例讲解)(转)

    前言 在Andrroid开发中,网络请求十分常用 而在Android网络请求库中,Retrofit是当下最热的一个网络请求库 今天,我将献上一份非常详细Retrofit v2.0的使用教程,希望你们会 ...

  2. 这是一份很详细的 Retrofit 2.0 使用教程(含实例讲解)

    前言 在Andrroid开发中,网络请求十分常用 而在Android网络请求库中,Retrofit是当下最热的一个网络请求库 今天,我将献上一份非常详细Retrofit v2.0的使用教程,希望你们会 ...

  3. 一份比较详细的DOS命令说明

    一份比较详细的DOS命令说明 1 echo 和 @ 回显命令 @                     #关闭单行回显 echo off              #从下一行开始关闭回显 @echo ...

  4. GitHub 上一份很受欢迎的前端代码优化指南

    http://segmentfault.com/a/1190000002587334?utm_source=weekly&utm_medium=email&utm_campaign=e ...

  5. GitHub 上一份很受欢迎的前端代码优化指南-强烈推荐收藏

    看到一份很受欢迎的前端代码指南,根据自己的理解进行了翻译,但能力有限,对一些JS代码理解不了,如有错误,望斧正. HTML 语义化标签 HTML5 提供了很多语义化元素,更好地帮助描述内容.希望你能从 ...

  6. 计算机网络(7)-----TCP协议概述

    传输控制协议(Transmission Control Protocol) 概念 一种面向连接的.可靠的.基于字节流的传输层通信协议,由IETF的RFC 793定义.在简化的计算机网络OSI模型中,它 ...

  7. [转] 整理了一份React-Native学习指南

    自己在学习React-Native过程中整理的一份学习指南,包含 教程.开源app和资源网站等,还在不断更新中.欢迎pull requests! React-Native学习指南 本指南汇集React ...

  8. 一份React-Native学习指南-感谢分享

    自己在学习React-Native过程中整理的一份学习指南,包含 教程.开源app和资源网站等,还在不断更新中.欢迎pull requests! React-Native学习指南 本指南汇集React ...

  9. TCP/IP详细解释--TCP/IP可靠的原则 推拉窗 拥塞窗口

    TCP和UDP在同一水平---传输层.但TCP和UDP最不一样的地方.TCP它提供了一个可靠的数据传输服务,TCP是面向连接的,那.使用TCP两台主机通过第一通信"拨打电话"这个过 ...

随机推荐

  1. HearthBuddy卡组

    偶数萨 手打两天已上传说,各位加油  欧洲牧羊人 ### 火元素换艾雅# 职业:萨满祭司# 模式:狂野模式## 2x (2) 图腾魔像        # 2x (2) 大漩涡传送门   # 2x (2 ...

  2. tomcat8踩坑:url包含|等特殊字符报错400的问题

    这个问题纠缠了我很久了,终于在今天早上解决了,感谢自己的不放弃和不断尝试的决心,我坚信,我可以找到解决方式!! 项目用的spring boot+spring security框架,关于统一错误页面在开 ...

  3. 如何实现一个串行promise

    异步执行任务A.B.C,...... 1.使用数组的reduce方法,reduce里有四个参数,pre,next,index,arr, 2.如果then方法里返回的是一个promise对象,那么执行下 ...

  4. [go]beego获取参数/返回参数

    获取前端传来的参数 获取数据并转为对应的类型 - ?id=111&id=122 c.GetInt("id") int,111 - ?id=111&id=122 c. ...

  5. js window事件解析(转载)

    js-window对象的方法和属性资料 hxpd 发表于 2007-05-08 21:58:18 熟练window对象的open.close.alert.confirm.prompt.setTimeo ...

  6. linux 基础 VIM 编辑器

  7. 基于redis的高并发秒杀的JAVA-DEMO实现!

    在Redis的事务中,WATCH命令可用于提供CAS(check-and-set)功能.假设我们通过WATCH命令在事务执行之前监控了多个Keys,倘若在WATCH之后有任何Key的值发生了变化,EX ...

  8. Window Position

    IE, Safari, Opera, and Chrome all provide screenLeft and screenTop properties that indicate the wind ...

  9. Java 多线程爬虫及分布式爬虫架构

    这是 Java 爬虫系列博文的第五篇,在上一篇 Java 爬虫服务器被屏蔽,不要慌,咱们换一台服务器 中,我们简单的聊反爬虫策略和反反爬虫方法,主要针对的是 IP 被封及其对应办法.前面几篇文章我们把 ...

  10. 【HANA系列】SAP HANA SQL条件判断是NULL的写法

    公众号:SAP Technical 本文作者:matinal 原文出处:http://www.cnblogs.com/SAPmatinal/ 原文链接:[HANA系列]SAP HANA SQL条件判断 ...