图解TCP/IP 记录

网关

负责将从传输层到应用层的数据进行转换和转发的设备。

典型例子：互联网邮件与手机邮件之间的转换服务。

---

 

 

---

 

IP：ip不具有重发机制，属于非可靠传输协议。

ICMP：ip数据包在发送途中一旦发生异常导致无法到达对端目标地址时，需要给发送端发送一个发生异常的通知，icmp就是为这一功能而制定的。

ARP：从分组数据包的ip地址中解析出物理地址（MAC地址）的一种协议。

TCP：面向有连接的传输协议，保证两端通信主机之间的通信可达。TCP能正确处理在传输过程中丢吧、传输顺序乱掉灯异常情况。为了建立与断开连接，有时它需要至少7次的发包收包，导致网络流量的浪费，为提高网络的利用率，TCP协议中定义了各种各样负责的规范，因此不利于视频会议（音频、视频的数据量既定）等场合使用。

UDP：面向无连接，常用于分组数据较少或多播、广播通信以及视频通信等多媒体领域。

FTP：进行文件传输时会建立两个TCP连接，分别是发出传输请求时所要用到的控制连接与实际传输数据时所要用到的数据连接。

---

 

包首部

每个包首部至少包含两个信息：1、发送端和接收端地址。2、上层协议类型。

TCP首部：包括源端口号和目标端口号（识别发送主机跟接收主机上的应用）、序号（用以发送的包中哪部分数据）、校验和（用以判断数据是否被损坏）。

IP首部：包含接收端IP地址以及发送端IP地址。紧随IP首部的还有用来判断其后面数据是TCP还是UDP的信息。IP包生成后，参考路由控制表决定接受此IP包的路由或主机。

以太网首部：包含接收端MAC地址、发送端MAC地址以及标志以太网类型的以太网数据的协议。根据上述信息产生的以太网数据包将通过物理层传输给接收端。

识别两端主机地址：1、以太网->MAC地址。2、IP->IP地址。3、TCP/UDP->端口号。

---

 

osi模型各层作用（添加的首部）

• 应用层：拿发邮件说，首部标明了邮件内容和收件人，若收件人邮箱无法接收新邮件（空间满），则返回一个错误给发送方，对这类异常的处理也属于应用层需要解决的问题。

• 表示层：将数据从主机特有的格式转换为网络标准传输格式，如字符集编码。

• 会话层：何时建立连接，何时发送数据。首部中记录着数据传送顺序的信息。

• 传输层：建立连接或断开连接，为确保所传输的数据到达目标地址，会在通信两端的计算机间进行确认，若没到达，则会重发。

• 网络层：数据通信处理（数据传输），负责将整个数据发送给最终目标地址。

• 数据链路层：发送一个分段内的数据。

• 物理层：将包含mac地址信息的首部附加到从网络层转发过来的数据上，将其发送到网络。

面向连接

发送数据前，需要在收发主机间连接一条通信线路。（如果对端主机关机或不存在，也就不可能建立连接，没有建立连接的主机也不可能发送数据过来）

面向无连接

不要求建立和断开连接。发送端可于任何时候自由发送数据，接收端永远不知道自己会在何时从哪里收到数据。（即使对端主机关机或不存在，数据包还是会被发送出去。因此，面向无连接的方式下可能会有很多冗余的通信）

---

 

为什么IP采用面向无连接?

1. 简化。

2. 提速。（管理每个连接想当繁琐。每次通信前建立连接会降低处理速度）

---

 

FTP：进行文件传输时会建立两个TCP连接，分别是发出传输请求时所要用到的控制连接与实际传输数据时所要用到的数据连接。

远程登录协议：TELNET、SSH

IPsec：是一个协议包，通过对IP协议的分组进行加密和认证来保护IP协议的网络传输协议族（一些相互关联的协议的集合）。只能工作在IP层。

---

 

IP地址由网络和主机两部分标识组成

网络地址必须保证相互连接的每个段的地址不相重复。而相同段内相连的主机必须有相同的网络地址。IP地址的“主机标识”则不允许在同一网段内重复出现。

这样IP地址具有了唯一性。

---

 

多播

用于将包发送给特定组内的所有主机。由于直接使用IP协议，因此也不存在可靠传输。

---

 

路由控制表

记录着网络地址与下一步应该发送至路由器的地址。若存在多条相同网络地址的的记录，就选择一个最吻合的网络地址（相同位数最多 ）。

---

 

IPv6

长度为128位，每16比特为一组，每组用冒号（“：”）隔开。如果出现连续0可省略这些0，并用两个冒号隔开（“：：”）

---

 

DNS如同互联网中的分布式数据库（使用UDP）

---

 

ICMP

作用：确认网络是否正常工作，以及遇到异常时进行问题诊断。

主要功能：确认IP包是否成功送达目标地址，通知在发送过程中IP包被废弃的具体原因，改善网络设置等。

---

 

TCP

TCP为提供可靠性传输，实行“顺序控制”或“重发控制”机制。此外还具备“流控制（流量控制）”、“拥塞控制”、提高网络利用率等众多功能。

 

TCP通过校验和、序列号、确认应答、重发控制、连接管理以及窗口控制等机制实现可靠性传输。

 

TCP/IP或UDP/IP中通常采用5个信息来识别一个通信。只要其中某一项不同，则认为是其他通信。

1. 源IP地址

2. 目标IP地址

3. 协议号（表示上层是TCP或UDP的一种编号）

4. 源端口号

5. 目标端口号

 

通过序列号与确认应答提高可靠性

当发送端的数据到达接收主机时，接收端主机会返回一个已收到消息的通知。这个消息叫做确认应答。

若发送端一定时间内没有等到确认应答，发送端就可以认为数据已经丢失，并进行重发。

未收到确认应答不一定意味着数据丢失，有可能是确认应答在途中丢失，导致发送端认为数据没有到达目的地从而重发，而目标主机会反复收到相同的数据，且必须放弃重复的数据包。为此就必须引入一种机制来识别是否已经接收数据又能判断是否需要接收。

确认应答处理、重发控制以及重读控制等功能都可以通过序列号实现。序列号是按顺序给发送数据的每一个字节（8位字节）都标上好吗的编号。接收端查询接收数据TCP首部中的序列号和数据的长度，将自己下一步应该接收的序列号作为确认应答返送回去，就这样通过序列号和确认应答号，TCP可实现可靠传输。

重发超时如何确定

重发超时是指在重发数据之前，等待确认应答到来的那个特定时间间隔。如果超过了这个时间仍未收到确认应答，发送端将进行数据重发。

超时都以0.5秒为单位进行控制，因此重发超时都是0.5秒的整数倍。不过，由于最初的数据包还不知道往返时间，所以其重发超时一般设置为6秒左右。数据被重发后若还是收不到确认应答，则进行再次发送。此时，等待确认应答的时间将会以2倍、4倍的指数函数延长。

此外，数据也不会被无限、反复地重发。达到一定重发次数后，如果仍没有任何确认应答返回，就会判断为网络或对端主机发生了异常，强制关闭连接。并且通知应用通信异常强行终止。

连接管理（三次握手四次挥手）

TCP在数据通信前，通过TCP首部发送一个SYN包作为建立连接的请求等待确认应答。如果对端发来确认应答，则认为可进行数据通信。如果对端的确认应答未到达，就不会进行数据通信。此外，在通信结束时会进行断开连接的处理（FIN包）

TCP以段为单位发送数据

在建立TCP连接的同时，也可确定发送数据包的单位，我们也可称其为“最大消息长度”。最理想的情况是，最长消息长度正好是IP中不会被分片处理的最大数据长度。

TCP在传送大量数据时，是以MSS的大小将数据进行分割发送。进行重发时也是以MSS为单位。MSS是在三次握手的时候，在两端主机间被计算得出。两端的主机在发出连接的请求时，会在TCP首部写入MSS选项，告诉对方自己的接口能够适应的MSS的大小。然后会在两者间选择一个较小的值投入使用。

利用窗口控制提高速度

TCP以1个段为单位吗，每发一个段进行一次确认应答的处理。这样的传输方式有一个缺点：包的往返时间越长通信性能就越低。为解决这个问题，TCP引入窗口这个概念。即使在往返时间较长的情况下，它也能控制网络性能的下降。确认应答不再是以每个分段，而是以更大的单位进行确认时，转发时间将会被大幅度的缩短，也就是说，发送端主机，在发送了一个段以后不必要一直等待确认应答，而是继续发送。

这个机制实现了使用大量的缓冲区，通过对多个段同时进行确认应答的功能。

窗口内的数据即便没有收到确认应答也可以发送出去。此外，从该窗口中（下图）能看到的数据因其某种数据已在传输中丢失，所以发送端才能收到确认应答，这种情况也需要进行重发。为此，发送端主机在等待确认应答返回之前，必须在缓冲区中保留这部分数据。在滑动窗口以外的部分包括尚未发送的数据以及已经确认对端已收到的数据。当数据发出后若如期收到确认应答就可以不用再进行重发，此时数据就可以从缓冲区清除。收到确认应答的情况下，将窗口滑动到确认应答中的序列号位置。这样可以顺序地将多个段同时发送提高通信性能。这种机制被称为滑动窗口控制。

窗口控制与重发控制

1. 确认应答未能返回的情况：数据已经到达对端，是不需要重发的，可以通过下一个确认应答进行确认。而在没有使用窗口控制的时候，没有收到确认应答的数据都会被重发。

2. 某个报文段丢失的情况：接收主机如果收到一个自己应该接收的序号以外的数据时，会针对当前为止收到数据返回确认应答。如图，当某一报文段丢失后，发送端会一直收到序号为1001的确认应答，这个确认应答好像在提醒发送端“我想接收的是从1001开始的数据”。在窗口比较大，有出现报文段丢失的情况下，同一个序号的确认应答将会被重复不断地返回。而发送端主机如果连续3次收到同一个确认应答，就会将其所对应的数据进行重发。这种机制比之前提到的超时管理更加高效，因此也被称作高速重发控制。

流控制

发送端根据自己的实际情况发送数据。但是，接收端可能收到的是一个毫无关系的数据包又可能会在处理其他问题上花费一些时间。因此在为这个数据包做其他处理时会耗费一些时间，甚至在高负荷的情况下无法接收任何数据。如此一来，如果接收端将本应该接收的数据丢弃的话就又会触发重发机制，导致网络流量的无端浪费。

为防止这种现象的发生，TCP提供一种机制可让发送端根据接收端的实际接收能力控制发送的数据量。这就是所谓的流控制。它的具体操作是，接收端主机向发送端主机通知自己可以接受数据的大小，于是发送端会发送不超过这个限度的数据。该大小限度就被称作窗口的大小，窗口大小的值就是由接收端主机决定的。

TCP首部中，专门有一个字段用来通知窗口大小。接收主机将自己可以接收的缓冲区大小放入这个字段中通知给发送端。这个字段的值越大，说明网络的吞吐量越高。

不过接收端的这个缓冲区一旦面临数据溢出时，窗口大小值也会随之被设置为一个更小的值通知给发送端，从而控制数据发送量。也就是说，发送端主机会根据接收端主机的提示，对发送数据的量进行控制。这也就形成了一个完整的TCP流控制（流量控制）。

拥塞控制

有了TCP的窗口控制，收发主机间即使不再以一个数据段为单位发送确认应答，也能够连续发送大量数据包。然而，如果在通信刚开始时就发送大量数据，也可能会引发其他问题。

一般来说，计算机网络都处在一个共享的环境。因此也有可能会因为其他主机之间的通信使得网络拥堵。在网络出现拥堵时，如果突然发送一个较大量的数据，极有可能会导致整个网络的瘫痪。

TCP为防止该问题的出现，在通信一开始时就会通过一个叫做慢启动的算法得出数值，对发送数据量进行控制。

首先，为了在发送端调节所要发送数据的量，定义一个叫“拥塞窗口”的概念。于是慢启动的时候，将这个拥塞窗口的大小设置为一个数据段（1MSS）发送数据，之后每收到一次确认应答（ACK），拥塞窗口的值就加1。在发送数据包时，将拥塞窗口的大小与接收端主机通知的窗口大小做比较，然后按照它们中较小的值，发送比其还要小的数据量。

如果重发采用超时机制，那么拥塞窗口的初始值可以设置为1以后再进行满启动修订。

随着包的每次往返，拥塞窗口也会以1、2、4等指数函数的增长，拥堵状况激增甚至导致网络拥塞的发送。为防止这些，引入慢启动阈值的概念。只要拥塞窗口的值超过这个阈值，在每收到一次确认应答时，只允许一下面这种比例放大拥塞窗口：

拥塞窗口越大，确认应答的数目也会增加。不过随着每收到一个确认应答，其涨幅也会逐渐减少，甚至小过比一个数据段还要小的字节数。因此，拥塞窗口的大小会呈直线上升的趋势。

TCP的通信开始时，并没有设置相应的慢启动阈值。而是在超时重发时，才会设置为当时拥塞窗口一半的大小。

由重复确认应答而出发的高速重发与超时重发机制的处理多少有些不同。因为前者需要至少3次的确认应答数据段到达对方主机后才会触发，相比后者网络的拥堵要轻一些。

而由重复确认应答进行高速重发控制时，慢启动阈值的大小被设置为当时窗口大小的一般。然后将窗口的大小设置为该慢启动阈值+3个数据段的大小。

TCP首部格式

 

---

 

UDP

常用语一下几个方面：

1、包总量较少的通信（DNS、SNMP等）

2、视频、音频等多媒体通信（即时通信）

3、限定于LAN等特定网络中的应用通信

4、广播通信（广播、多播）

UDP首部格式

提高网络利用率规范

Nagle算法（TCP中为了提高网络的利用率）(可能会产生粘包的问题)

该算法是指发送端即使还有应该发送的数据，但如果这部分数据很少的话，则进行延迟发送的一种处理机制。具体来说，就是仅在下列任意一种条件下才能发送数据。如果两个条件都不满足，那么暂时等待一段时间以后再进行数据发送。

• 已发送的数据都已经收到确认应答时。

• 可以发送最大段长度（MSS）的数据时。

根据这个算法虽然网络利用率可以提高，但是可能会发送某种程度的延迟。为此，在窗口系统以及机械控制等领域中使用TCP时，往往会关闭对该算法的启用。

---

 

TELNET

TELNET利用TCP的一条连接，通过这一条连接向主机发送文字命令并在主机上执行。

 

SSH（端口22）

SSH是加密的远程登录系统。TELNET中登录时无需输入密码就可以发送，容易造成通信窃听和非法入侵的危险。使用SSH后可以加密通信内容。即使信息被窃听也无法破解所发送的密码、具体命令以及命令返回的结果是什么。

SSH功能：

1. 可使用更强的认证机制。

2. 可转发文件。

3. 可使用端口转发功能。

 

FTP（端口21、20）

使用两条TCP连接：一条用来控制，另一条用于数据（文件）的传输。

用于控制的TCP连接

主要在FTP的控制部分使用。例如登录用户名和密码的验证、发送文件的名称、发送方式的设置。使用TCP21号端口，在TCP21号端口上进行文件GET(RETR)、PUT(STOR)、以及文件一览(LIST)等操作时，每次都会建立一个用于数据传输的TCP连接。数据的传输和文件一览表的传输正式在这个新建的连接上进行。当数据传输完毕后，传输数据的这条连接也会被断开，然后会在控制用的连接上继续进行命令或应答的处理。通常同于数据传输的TCP连接是按照与控制用的连接相反的方式建立的。因此，在通过NAT连接外部FTP服务器的时候，无法直接建立传输数据时使用的TCP连接。此时，必须使用PASV命令修改建立的方向才行。在用户要求断开之前会一直保持连接状态。不过绝大多数FTP服务器都会对长时间没有任何新命令输入的用户的连接强行断开。

数据传输用的TCP连接

使用端口20，不过可以用PORT命令修改为其他值。最近，出于安全考虑，普遍在数据传输用的端口号中使用随机数进行分配。

 

---

 

HTTP（端口80）

 

---

 

加密技术

 

对称加密方式包括：

AES、DES

非对称加密方式包括：

RSA、DH

 

 

 

---

 

TLS/SSL与HTTPS（端口443）

在HTTPS中采用对称加密方式，而在发送其公钥时采用的是非对称加密方式。

 

---

 

什么是TCP粘包问题

TCP粘包就是指发送方发送的若干包数据到达接收方时粘成了一包，从接收缓冲区来看，后一包数据的头紧接着前一包数据的尾，出现粘包的原因是多方面的，可能是来自发送方，也可能是来自接收方。

产生粘包的情况有两种：

1.发送方原因

TCP默认使用Nagle算法（主要作用：减少网络中报文段的数量），而Nagle算法主要做两件事：

1、只有上一个分组得到确认，才会发送下一个分组

2、收集多个小分组，在一个确认到来时一起发送

Nagle算法造成了发送方可能会出现粘包问题

 

2.接收方原因

TCP接收到数据包时，并不会马上交到应用层进行处理，或者说应用层并不会立即处理。实际上，TCP将接收到的数据包保存在接收缓存里，然后应用程序主动从缓存读取收到的分组。这样一来，如果TCP接收数据包到缓存的速度大于应用程序从缓存中读取数据包的速度，多个包就会被缓存，应用程序就有可能读取到多个首尾相接粘到一起的包。

什么时候需要处理粘包现象

1. 如果发送方发送的多组数据本来就是同一块数据的不同部分，比如说一个文件被分成多个部分发送，这时当然不需要处理粘包现象

2. 如果多个分组毫不相干，甚至是并列关系，那么这个时候就一定要处理粘包现象了

如何处理粘包现象

（1）发送方

对于发送方造成的粘包问题，可以通过关闭Nagle算法来解决，使用TCP_NODELAY选项来关闭算法。

（2）接收方

接收方没有办法来处理粘包现象，只能将问题交给应用层来处理。

（2）应用层

应用层的解决办法简单可行，不仅能解决接收方的粘包问题，还可以解决发送方的粘包问题。

解决办法：循环处理，应用程序从接收缓存中读取分组时，读完一条数据，就应该循环读取下一条数据，直到所有数据都被处理完成，但是如何判断每条数据的长度呢？

1. 格式化数据：每条数据有固定的格式（开始符，结束符），这种方法简单易行，但是选择开始符和结束符时一定要确保每条数据的内部不包含开始符和结束符。

2. 发送长度：发送每条数据时，将数据的长度一并发送，例如规定数据的前4位是数据的长度，应用层在处理时可以根据长度来判断每个分组的开始和结束位置。