TCP/IP 介绍
TCP/IP Transmission Control Protocol/Internet Protocol 传输控制协议/因特网互联协议
TCP/IP是一个Protocol Stack (协议栈)，包括TCP、IP、UDP、ICMP、RIP、TELNET、FTP、SMTP、ARP等许多协议。
最早发源于1969年美国国防部（缩写为DoD）的因特网的前身ARPA网络项目，1983年1月1日，TCP/IP取代了旧的网络控制协议NCP，成为今天的互联网和局域网的基石和标准,由互联网工程任务组负责维护国防高级研究计划局DARPA与BBN技术公司、斯坦福大学和伦敦大学学院签约，在多个硬件平台上开发协议的操作版本。 在协议开发过程中，数据包路由层的版本号从版本 1 进展到版本 4，后者于 1983 年安装在 ARPANET 中。它被称为互联网协议版本4（IPv4）作为协议，仍在互联网使用，连同其目前的继承，互联网协议版本6（IPv6）。
TCP/IP 分层
共定义了四层，和 OSI参考模型的分层有对应关系
RFC官方分为四层:
- Application Layer （应用程序层）
- Transport Layer （传输层）
- Internet Layer （ 网络层）
- Link Layer(media-access) (链路层(媒体访问))
TCP/IP和OSI模型的比较
-
相同点
两者都是以协议栈的概念为基础
协议栈中的协议彼此相互独立
下层对上层提供服务
-
不同点
OSI是先有模型；TCP/IP是先有协议，后有模型
OSI是国际标准，适用于各种协议栈；TCP/IP实际标准，只适用于TCP/IP网络
层次数量不同
关于 TCP 和 UDP
TCP面向连接的协议：TCP是面向连接的、可靠的进程到进程通信的协议。TCP提供全双工服务，即数据可在同一时间双向传输，每一个TCP都有发送缓存和接收缓存，用来临时存储数据。。 TCP 在传输 真实数据 前会进行链接测试 （三次握手），如果测试通过才会发送数据，否则不会发送真实数据。
面向连接网络协议：是指通信双方之间在进行通信之前要先建立连接。比如打电话，双方通话前需要先建立连接。等数据发送结束后，双方再断开连接。
UDP协议是无连接、不保证可靠性的传输层协议。发送端不关心发送的数据是否到达目标主机、数据是否出错等，收到数据的主机也不会告诉发送方是否收到了数据，它的可靠性由上层协议来保障。传输数据速度更快，效率更高
无连接网络协议：是指通信双方不需要事先建立一条通信线路，而是把每个带有目的地址的包送到网络线路上，由系统自主选定路线进行传输。比如QQ发送信息。
| 可靠的 | 快但不可靠 | |
|---|---|---|
| 连接类型 | 面向连接 | 无连接网 |
| 协议 | TCP | UDP |
| 是否测试 | 是 | 否 |
| 使用场景 |
|
|
TCP 和 UDP 的基本区别：
- 基于连接和无连接
- 流模式和数据报格式
- TCP保证数据正确性 ， UDP 可能丢包
- TCP保证数据顺序，UDP不保证
- TCP要求系统资源较多，UDP较少
- UDP程序结构简单
- TCP 只能一对一 UDP支持一对一 ， 多对多 ，一对多 ， 多对一
- TCP 首部开销 20字节 ； UDP 首部开销小 ，只有8个字节。
- TCP的逻辑通信信道是全双工的可靠信道 ， UDP则是不可靠信道 。
TCP特性
- 工作在传输层
- 面向连接协议
- 全双工协议
- 半关闭 断开
- 错误检查 （校验 数据包有问题会重新传）
- 将数据打包成段，排序 （给数据 排序）
- 确认机制 对面每发一个包，我会告诉对面我收到了
- 数据恢复，重传
- 流量控制，滑动窗口
TCP报文段
-
源端口、目标端口：计算机上的进程要和其他进程通信是要通过计算机端口的，而一个计算机端口某个时刻只能被一个进程占用，所以通过指定源端口和目标端口，就可以知道是哪两个进程需要通信。源端口、目标端口是用16位表示的，可推算计算机的端口个数为2^16个,即 65536 （0-65535）
-
序列号：seq（Sequence Number）序号占32位，用来标识从计算机A发送到计算机B的数据包的序号，计算机发送数据时对此进行标记。 在TCP连接中所传送的字节流的每一个字节都会按顺序编号。 由于序列号由32位表示，所以每2^32个字节，就会出现序列号回绕，再次从0 开始 无限循环
-
确认号（ack）：表示接收方期望收到发送方下一个报文段的第一个字节数据的编号。也就是告诉发送方：我希望你（指发送方）下次发送的数据的第一个字节数据的编号为此确认号：传输是否有问题？ ack = seq + 1
确认号的作用：告诉对方我收到了你的消息
-
数据偏移／首部长度：表示TCP报文段的首部长度，共4位，由于TCP首部包含一个长度可变的选项部分，需要指定这个TCP报文段到底有多长。它指出 TCP 报文段的数据起始处距离 TCP 报文段的起始处有多远。该字段的单位是32位(即4个字节为计算单位），4位二进制最大表示15，所以数据偏移也就是TCP首部最大60字节
-
控制位：每个控制位占用1Bit，共有6个，描述了A B 两台电脑目前处于什么状态 ，分别为 URG、ACK、PSH、RST、SYN、FIN，具体含义如下：
| URG（紧急位） | 紧急指针（urgent pointer）有效。 |
| ACK（确认位） | 确认序号有效。 |
| PSH（急切位） | 接收方应该尽快将这个报文交给应用层。 |
| RST（重置位） | 重置连接。 |
| SYN（同步位） | 建立一个新连接。 |
| FIN（断开位） | 断开一个连接。 |
-
窗口大小：表示现在允许对方发送的数据量，也就是告诉对方，从本报文段的确认号开始允许对方发送的数据量，达到此值，需要ACK确认后才能再继续传送后面数据，由Window size value * Window size scaling factor（此值在三次握手阶段TCP选项Window scale协商得到）得出此值
调节每次发送的数据包量。
服务端和客户端之间 会根据实际情况 自动调节每次发的数据包的个数。
-
校验和：提供额外的可靠性紧急指针：标记紧急数据在数据字段中的位置
-
选项部分：其最大长度可根据TCP首部长度进行推算。TCP首部长度用4位表示，选项部分最长为：(2^4-1)*4-20=40字节
TCP 三次握手
三次握手简述：三次握手，即客户端与服务端进行的三次通信。
三次握手的目的：三次握手是为了让客户端和服务端分别确认自己和对方接收和发送消息的能力是正常的。
为什么只有三次握手才能确认双方的接受与发送能力是否正常，而两次却不可以？
- 第一次握手：客户端发送一个SYN报文，服务端收到了。这样服务端就能得出结论：客户端的发送能力、服务端的接收能力是正常的。
- 第二次握手：服务端发送送一个SYN + ACK 报文，客户端收到了。这样客户端就能得出结论：服务端的接收、发送能力，客户端的接收、发送能力是正常的。但是 服务端 并不能确认客户端的接收能力是否正常。
- 第三次握手：客户端发包，服务端收到了。这样服务端就能得出结论：客户端的接收、发送能力正常，服务端自己的发送、接收能力也正常。
因此，需要三次握手才能确认双方的接收与发送能力是否正常。
精简版：
- 第一次握手：客户端给服务器发送一个 SYN 报文。
- 第二次握手：服务器收到 SYN 报文之后，会应答一个 SYN+ACK 报文。
- 第三次握手：客户端收到 SYN+ACK 报文之后，会回应一个 ACK 报文。
- 服务器收到 ACK 报文之后，三次握手建立完成。
详细版：
第一次握手：
当客户端向服务端发送请求连接的报文时：
seq序列号=x（x为随机） SYN=1（表示发送连接请求）
第二次握手：
服务端收到客户端发来的请求报文后，同意建立连接，则向客户端发送确认报文：
seq序列号=y （这时服务器也会产生一个序列号y，和客户端的序号不相关）
ack确认号=x+1 （seq序列号x+1，表示确认收到了客户端的请求）
ACK=1 （表示这是条确认请求）
SYN=1 （同时也发送一个建立连接的请求）
第三次握手：
客户端进程收到服务端进程的确认后，还要向服务端给出确认，然后连接成功建立：
seq序列号=x+1 （这时客户端的序号为1）
ack确认号=y+1 （表示确认收到了服务器的连接请求）
ACK=1 （表示这是确认报文）
| 序号 | 报文路径 | 客户端状态 | 报文信息 | 服务器状态 | 目的 |
|---|---|---|---|---|---|
| 第一次握手 | A-->B | SYN-SENT | SYN=1,seq=x | LISTEN | A:自己发信息正常 B:自己接收信息正常，A发消息正常。 |
| 第二次握手 | B-->A | SYN-SENT | SYN=1,ACK=1, seq=y,ack=x+1 | SYN-RCVD | A:自己收、发信息正常，B收、发信息正常 B:自己收、发信息正常，A发信息正常，但还不知道A是否能收到消息。 |
| 第三次握手 | A-->B | ESTAB-LISHED | ACK=1,seq=x+1,ack=y+1 | ESTAB-LISHED | A：都正常 B: 都正常 |
初始时，客户端处于CLOSED(closed) 状态，服务器处于 LISTEN（listen）状态。
第一次握手： 客户端发送SYN报文给服务器，初始序列号为x（seq=x）, 此时客户端进入SYN_SENT状态；这时，客户端可以知道自己发送能力正常，服务器可以知道自己接收能力正常，客户端发送能力正常。
第二次握手：服务器通过自己的SYN报文给与客户端 确认和响应，服务器进入SYN_RECV状态；这时客户端可以知道服务器收发能力正常，自己收发能力正常；服务器知道自己收发能力正常，但不知道客户端接收能力正常，因此需要第三次握手。
第三次握手：客户端收到服务器的SYN+ACK的包，此时客户端处于ESTAB-LISHED（已确认）状态，表示客户端和服务器都表示同意连接，因此客户端发送一个ACK报文，ack仍为序列号+1，即y+1,初始序列号为x，因此客户端发送的第二次报文，序列号要+1，即x+1;这时服务器可以确认客户端收发能力正常；第三次握手可以携带数据。
- SYN=1 时的报文不能携带数据，如果可以携带数据的话，如果有人在第一次握手的SYN报文放入很多数据，重复发送大量的这些报文，服务器就会消耗大量内存缓存这些报文，服务器就更容易被攻击。
TCP四次挥手
MSL :Maximum Segment Lifetime 解除 连接关系
2msl 2倍的数据发送时间。
TCP是全双工的工作模式，因此每个方向都必须单独进行关闭。当一方完成自己的数据发送任务后，就可以发送一个FIN报文来终止这个方向的连接。
全双工：客户端在给服务器端发送消息的同时，服务端也可以给客户端发送消息；
半双工：客户端可以给服务端发消息，服务端也可以给客户端发消息，但客户端和服务端不能同时发。
四次挥手详解：
刚开始客户端和服务器端都处于ESTAB-LISHED状态，假如客户端发起关闭请求
- 第一次挥手：客户端向服务器发送FIN报文（FIN=1,seq=u），发完后进入 FIN-WAIT-1 状态，即主动关闭TCP连接，不再发送数据，但可以接收服务器发来的报文，等待服务器回复
- 第二次挥手：服务器接到FIN报文后，返回一个ACK报文（ACK=1,ack=u+1,seq=v），表明自己接收到此报文，服务器进入 CLOSE-WAIT 关闭等待状态，此时客户端就知道服务端接到自己的断开连接请求，进入到 FIN-WAIT-2 状态，TCP处于半关闭状态，但服务器端可能还有数据要传输。
- 第三次挥手：服务器关闭客户端连接，发送FIN报文（FIN=1，seq=w,ack=u+1）给客户端，此时服务器处于 LAST-ACK 状态，等待客户端回应。
- 第四次挥手：客户端收到FIN报文后，发送一个ACK（ACK=1,ack=w+1,seq=u+1）给服务器作为应答，此时客户端处于 TIME-WAIT 状态，这个状态是为了等待足够的时间以确保TCP接收到连接中断请求的确认。
- 注意：这时服务器到客户端的TCP连接并未被释放，客户端需要经过等待2MSL（MSL表示一个报文的来回时间）后才会进入 CLOSED 状态，这样做的目的是确保服务器收到自己的ACK报文，如果在规定时间没有收到客户端发的ACK，那么服务器会重发FIN，客户端再次收到FIN报文，就知道自己的ACK丢了，然后会重发ACK给服务器。服务器收到ACK后，就会关闭连接，处于CLOSE状态了。
| 序号 | 报文路径 | 客户端状态 | 报文信息 | 服务器状态 |
|---|---|---|---|---|
| 第一次挥手 | A-->B | FIN-WAIT-1 | FIN=1,seq=u | ESTAB-LISHED |
| 第二次挥手 | B-->A | FIN-WAIT-2 | ACK=1,seq=v,ack=u+1 | CLOSE-WAIT |
| 第三次挥手 | B-->A | FIN-WAIT-2 | FIN=1,seq=v,ack=u+1 | LAST-ACK |
| 第四次挥手 | A-->B | TIME-WAIT | ACK=1,ack=w+1,seq=u+1 | CLOSED |
关于四次挥手里的一些问题
等待 2MSL 的原因：
- 防⽌客户端最后⼀次发给服务器的确认在⽹络中丢失以⾄于客户端关闭，⽽服务端并未关闭，导致资源的浪费。
- 等待最⼤的2msl可以让本次连接的所有的⽹络包在链路上消失，以防造成不必要的⼲扰。
客户端为什么会要有 TIME-WAIT 状态：
- 如果最终的ACK丢失，服务器会重发FIN，客户端必须维护TCP状态信息以便可以重发最终的ACK，否则就发送RST（TCP连接出错），结果服务端认为发生错误。
- TCP实现必须可靠地终止连接的两个方向（全双工关闭），客户端必须进入TIME_WAIT状态，以免可能出现重发ACK的情形。
为什么挥手比握手多一次
因为握手的时候并没有数据传输，所以服务端的 SYN 和 ACK 报文可以一起发送 ，但是挥手的时候有数据在传输，所以 ACK 和 FIN报文不能同时发送，需要分两步，所以会比握手多一步。
为什么三次挥手不行
因为服务端在接收到FIN, 往往不会立即返回FIN ，必须等到服务端所有的报文都发送完毕了，才能发FIN。因此先发一个ACK表示已经收到客户端的FIN，延迟一段时间才发FIN。这就造成了四次挥手。
如果是三次挥手会造成：
如果将服务端的两次挥手合为一次，等于说服务端将ACK和FIN的发送合并为一次挥手，这个时候长时间的延迟可能会导致客户端误以为FIN没有到达客户端，从而让客户端不断的重发FIN。所有只能第二次握手先发送ACK确认接收到了客户端的数据，等服务器发送完了数据，再发送FIN包进行第三次挥手。
在三次握手和四次挥手中，报文发送都会携带一些参数，这些参数的具体解释如下：
- SYN：同步序列号标志位,tcp三次握⼿中，第⼀次会将SYN=1,ACK=0，此时表⽰这是⼀个连接请求报⽂段，对⽅会将SYN=1,ACK=1，表⽰同意连接，连接完成之后将SYN=0
- FIN：在tcp四次挥⼿时第⼀次将FIN=1，表⽰此报⽂段的发送⽅数据已经发送完毕，这是⼀个释放链接的标志
- ACK：当ACK=1时，我们的确认序列号ack才有效，当ACK=0时，确认序号ack⽆效,TCP规定：所有建⽴连接的ACK必须全部置为1
- 序号(seq): 占 32位4 个字节，序号范围[0，2^32-1]，序号增加到 2^32-1 后，下个序号又回到 0。TCP 是面向字节流的，通过 TCP 传送的字节流中的每个字节都按顺序编号，而报头中的序号字段值则指的是本报文段数据的第一个字节的序号。例如:我们的seq = 201，携带的数据有100，那么最后⼀个字节的序号就为300，那么下⼀个报⽂段就应该从301开始.
- 确认号(ack): 占 32位4 个字节，期望收到对方下个报文段的第一个数据字节的序号。当标志位ACK值为1时，才能产生有效的确认号ack。并且:ack=seq+1;
- RST：当RST=1时，表明TCP连接出现严重错误，此时必须释放连接，之后重新连接,⼜叫重置位.
- URG：紧急指针标志位，当URG=1时，表明紧急指针字段有效.它告诉系统中有紧急数据，应当尽快传送，这时不会按照原来的排队序列来传送.⽽会将紧急数据插⼊到本报⽂段数据的最前⾯
- PSH：推送操作,提示接收端应用程序立即从TCP缓冲区把数据读走
有限状态机（扩展）
- CLOSED 没有任何连接状态
- LISTEN 侦听状态，等待来自远方TCP端口的连接请求 （服务开启 http（进程） 80端口在帮进程 看着 有没有人找 http ）
- SYN-SENT 在发送连接请求后，等待对方确认
- SYN-RECEIVED 在收到和发送一个连接请求后，等待对方确认
- ESTABLISHED 代表传输连接建立，双方进入数据传送状态
- FIN-WAIT-1 主动关闭,主机已发送关闭连接请求，等待对方确认
- FIN-WAIT-2 主动关闭,主机已收到对方关闭传输连接确认，等待对方发送关闭传输连接请求
- TIME-WAIT 完成双向传输连接关闭，等待所有分组消失
- CLOSE-WAIT 被动关闭,收到对方发来的关闭连接请求，并已确认
- LAST-ACK 被动关闭,等待最后一个关闭传输连接确认，并等待所有分组消失
- CLOSING 双方同时尝试关闭传输连接，等待对方确认
TCP超时重传
异常网络状况下（开始出现超时或丢包），TCP控制数据传输以保证其承诺的可靠服务
TCP服务必须能够重传超时时间内未收到确认的TCP报文段。为此，TCP模块为每个TCP报文段都维护一个重传定时器，该定时器在TCP报文段第一次被发送时启动。如果超时时间内未收到接收方的应答，TCP模块将重传TCP报文段并重置定时器。至于下次重传的超时时间如何选择，以及最多执行多少次重传，就是TCP的重传策略
UDP协议
UDP特性
- 工作在传输层
- 提供不可靠的网络访问
- 非面向连接协议 无连接
- 有限的错误检查
- 传输性能高 快
- 无数据恢复特性
telnet 协议
远程连接的 协议 远程管理协议
功能：探测 远端服务器端口
格式： telnet IP 端口号
远程 telnet
| （1）password方式 [R1-ui-vty0-4]authentication-mode password
修改用户权限 |
扫一扫
49万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
