计算机网络

OSI模型、有几层

• OSI即开放式系统互联。ISO（国际标准化组织）为了更好的使网络应用更为普及，推出了OSI模型，这样所有的公司都按照统一的标准来指定自己的网络，就可以互联普及了
• OSI定义网络互联的七层模型（物理层、数据链路层、网络层、传输层、会话层、表示层、应用层）

OSI七层模型	功能	对应的网络协议
应用层	文件传输、文件管理、电子邮件的处理---dpdu	HTTP、TFTP、FTP、NFS、WAIS、SMTP
表示层	确保一个系统的应用层发送的消息可以被另一个系统的应用层读取，编码转换，数据解析，管理数据的解密和加密，最小单位---ppdu	TeInet、Rlogin、SNMP、Gopher
会话层	负责在网络中的两节点的建立、维持和终止通信，在一层协议中，可以解决节点连接的协调和管理问题。包括通信连接的建立，保持会话过程通信连接的畅通，两节点之间的对话，决定通信是否被终端终止，通信终端从何处重新发送，最小单位---spdu	SMTP、DNS
传输层	定义一些传输数据的协议和端口，传输协议同时进行流量控制，或是根据接收方接收数据的快慢程度，规定适当的发送速率，解决传输效率及能力的问题---tpdu	TCP、UDP
网络层	控制子网的运行，如逻辑编址，分组传输，路由选择的最小的单位-分组（包）报文	IP、ICMP、ARP、RARP、AKP、UUCP
数据链路层	主要是对物理层传输的比特流包装，检测保证数据传输的可靠性，将物理层接收的数据进行MAC(媒体访问控制)地址的封装和解封装，也可以简单的理解为物理寻址。交换机就处在这一层，最小的传输单位——帧	Ethernet
物理层	定义物理设备的标准，主要对物理连接方式，电气特性，机械特性等制定统一标准，传输比特流，因此最小的传输单位——位(比特流)	IEEE 802.1A, IEEE 802.2到IEEE 802.

TCP/IP四层模型	功能	常见协议	所对应OSI七层模型
应用层	为计算机用户提供应用接口，为用户直接提供各种网络服务	HTTP、HTTP5，FTP，TELNET	应用层、表示层、会话层
传输层	建立主机端到端的连接，为上层协议提供端到端的可靠和透明的数据传输服务，处理差错控制和流量控制，向高层屏蔽了下层数据通信的细节	TCP、UDP	传输层
网络层	通过ip寻址来建立两个节点之间的连接，为源端的运输层传来分组，选择合适的路由和交互节点，正确无误地按照地址传送给目的端的运输层。	IP	网络层
数据链路层	通过一些规程或协议来控制这些数据的传输，以保证被传输数据的正确性。实现这些规程或协议的硬件和软件加到物理线路		物理层、数据链路层

TCP、UDP区别

• TCP是面向连接的协议，发送数据前要先建立连接，TCP提供可靠的服务，通过TCP连接传输的数据不会丢失，没有重复，并且按顺序到达
• UDP是无连接的协议，发送数据前不需要建立连接，没有可靠性
• TCP通信类似于要打个电话，接通了，确定身份后，才开始进行通信
• UDP通信类似于学校的广播，靠着广播播报就可以直接通信了
• TCP只支持点到点的通信，UDP支持一对一，一对多，多对一，多对多通信
• TCP是面向字节流的，UDP是面向报文的；面对字节流是指发送数据时以字节为单位，一个数据包可以拆分成若干组进行发送，而UDP一个报文只能一次发完
• TCP首部开销（20字节）比UDP（8字节）大
• UDP的主机不需要维持复杂的连接状态表

TCP、UDP的使用场景

• UDP：实时性要求比较高的情况，如游戏、媒体通信、实时直播、即使出现传输错误也可以容忍
• TCP：其他情况都用TCP、HTTP都用TCP，因为要求传出的内容可靠，不出现丢失的情况

形容一下TCP、UDP

• TCP通信可看做打电话：李三(拨了个号码)：喂，是王五吗？ 王五：哎，您谁啊？ 李三：我是李三，我想给你说点事儿，你现在方便吗？ 王五：哦，我现在方便，你说吧。 甲：那我说了啊？ 乙：你说吧。 (连接建立了，接下来就是说正事了…)
• UDP通信类似于学校里的广播：播音室：喂喂喂！全体操场集合

如何实现UDP可靠传输

• 在类似于应用层重新实现TCP
• 添加seq/ack机制，确保数据发送到对端。
• 收方收到UDP之后回复个确认包，发送方有个机制，收不到确认包就要重新发送，每个包有递增的序号，接收方发现中间丢了包就要发重传请求。
• 当网络太差时候频繁丢包，防止越丢包越重传的恶性循环，要有个发送窗口的限制，发送窗口的大小根据网络传输情况调整，调整算法要有一定自适应性。

TCP三次握手

• 具体细节：
  1. 第一次握手：Client将SYN置1，随机产生一个初始序列号seq发送给Server，进入SYN_SENT状态；
  2. 第二次握手：Server收到Client的SYN=1之后，知道客户端请求建立连接，将自己的SYN置1，ACK置1，产生一个acknowledge number=sequence number+1，并随机产生一个自己的初始序列号，发送给客户端；进入SYN_RCVD状态
  3. 第三次握手：客户端检查acknowledge number是否为序列号+1，ACK是否为1，检查正确之后将自己的ACK置为1，产生一个acknowledge number=服务器发的序列号+1，发送给服务器；进入ESTABLISHED状态；服务器检查ACK为1和acknowledge number为序列号+1之后，也进入ESTABLISHED状态；完成三次握手，连接建立。
• 简单来说
  1. 客户端向服务端发送SYN
  2. 服务端返回SYN，ACK
  3. 客户端发送ACK

三次握手必要性

• 三次握手的目的就时建立可靠的通信信道，主要目的就是双方确认自己与对方的发送与接收机能正常
  1. 第一次握手：客户什么都不能确认；服务端确认了对方发送正常，自己接收正常
  2. 第二次握手：客户确认了自己发送正常，接收正常，对方发送正常，接收正常；服务端确认了自己接收正常，对方发送正常
  3. 第三次握手：客户确认了自己发送正常、接收正常，对方发送、接收正常；服务端确认了自己发送、接收正常，对方发送、接收正常，因此第三次握手才确认了双发的发送、接受都正常，缺一不可。

建立连接可以两次握手吗？

• 不可以
• 因为可能出现已失效的请求连接请求报文段（在某个网络节点滞留了）传到服务端，但是此时客户端并没有发起建立连接的请求，并不会理睬server的确认，而server却已经认为请求已经建立，一直等着client发来数据，白白耗费资源。三次握手就可以防止此种情况发生
• 两次握手server无法确认client是否收到确认，无法保证Client和Server之间成功互换初始序列号

可以采用四次握手吗？

• 可以。三次握手都能保证连接成功建立了，何况是四次，但是这样降低了传输速率

第三次握手中个，如果客户端的ACK未送达服务器会怎样？

• sever：每隔三秒重发SYN、ACK至客户端（默认五次，server仍未收到ACK则关闭连接进入CLOSED状态）
• client
  1. server进行重发过程中，client向服务器发送数据，若数据头部的ACK为1，则server收到数据后读取ACK number，进入established状态
  2. 当server已经进入Closed状态，如果client向服务器发送数据，服务器应答RST包

建立连接后，client出现故障

• server每次收到client的请求后会将定时器复位，若两小时内都未收到client的请求，sever发送给client探测报文段（每隔75秒钟发送一次），连发十次探测报文未仍然未回应，server则关闭连接。

什么是SYN洪泛攻击，怎么解决

• A（攻击者）发送TCP SYN，SYN是TCP三次握手中的第一个数据包，而当这个服务器返回ACK以后，A不再进行确认，那这个连接就处在了一个挂起的状态，也就是半连接的意思，那么服务器收不到再确认的一个消息，还会重复发送ACK给A。这样一来就会更加浪费服务器的资源。A就对服务器发送非法大量的这种TCP连接，由于每一个都没法完成握手的机制，所以它就会消耗服务器的内存最后可能导致服务器死机，就无法正常工作了。更进一步说，如果这些半连接的握手请求是恶意程序发出，并且持续不断，那么就会导致服务端较长时间内丧失服务功能——这样就形成了DoS攻击。这种攻击方式就称为SYN泛洪攻击。
• 解决方式：优化主机系统设置。比如降低SYN timeout时间，使得主机尽快释放半连接的占用或者采用SYN cookie设置，如果短时间内收到了某个IP的重复SYN请求，我们就认为受到了攻击。我们合理的采用防火墙设置等外部网络也可以进行拦截。

初始序列号是什么

• TCP连接的一方A，随机选择一个32位的序列号作为发送数据的初始序列号（如seq=1000），以该序列号为原点，对要传送的数据进行编号，把这个初始序列号发给B，以便在传输数据时，B可以确认怎么样的数据编号是合法的，同时在数据传输时，A还可以确认B收到的每一个字节（如A收到B的确认编号ack为2001，A就知道了编号为1001-2000的数据都被B成功接收了）

有哪些保证TCP能正确收发数据的机制

TCP保证可靠性主要依靠下面7种机制：

• 1、检验和 TCP检验和的计算与UDP一样，在计算时要加上12byte的伪首部，检验范围包括TCP首部及数据部分，但是UDP的检验和字段为可选的，而TCP中是必须有的。计算方法为：在发送方将整个报文段分为多个16位的段，然后将所有段进行反码相加，将结果存放在检验和字段中，接收方用相同的方法进行计算，如最终结果为检验字段所有位是全1则正确（UDP中为0是正确），否则存在错误。
• 2、序列号 TCP将每个字节的数据都进行了编号，这就是序列号。
• 序列号的作用：
  • a、保证可靠性（当接收到的数据总少了某个序号的数据时，能马上知道）
  • b、保证数据的按序到达
  • c、提高效率，可实现多次发送，一次确认
  • d、去除重复数据 数据传输过程中的确认应答处理、重发控制以及重复控制等功能都可以通过序列号来实现
• linux系统初始序列号如何生成？
  • 基于时钟的方案，针对每一个连接为时钟设置随机的偏移量，随机偏移量是在连接标识（即4元组）的基础上利用加密散列函数得到的。散列函数的输入每隔5分钟就会改变一次。32位初始序列号，最高八位是保密的序列号，剩余的各位则由散列函数生成。
  • windows下基于RC4的类似方法
• 为什么初始序列号需要保证重启后上一连接的延迟报文段不能影响当前连接？
  • 因为可以相信延迟的报文段又会被视为有效数据重新进入新连接的数据流中，所以要避免连接实例间的序列号重叠问题，可以在应用层使用CRC或校验和保证数据完整性
• 3、确认应答机制（ACK） TCP通过确认应答机制实现可靠的数据传输。在TCP的首部中有一个标志位——ACK，此标志位表示确认号是否有效。接收方对于按序到达的数据会进行确认，当标志位ACK=1时确认首部的确认字段有效。进行确认时，确认字段值表示这个值之前的数据都已经按序到达了。而发送方如果收到了已发送的数据的确认报文，则继续传输下一部分数据；而如果等待了一定时间还没有收到确认报文就会启动重传机制。 正常情况下的应答机制：

• 4、超时重传机制 当报文发出后在一定的时间内未收到接收方的确认，发送方就会进行重传（通常是在发出报文段后设定一个闹钟，到点了还没有收到应答则进行重传），其基本过程如下：

当然，未收到确认不一定就是发送的数据包丢了，还可能是确认的ACK丢了：

当接收方接收到重复的数据时就将其丢掉，重新发送ACK。而要识别出重复的数据，就要用到前面提到的序列号了，利用序列号很容易就可以做到去重的效果。 重传时间的确定：报文段发出到收到应答中间有一个报文段的往返时间RTT，显然超时重传时间RTO会略大于这个RTT，TCP会根据网络情况动态的计算RTT，即RTO是不断变化的。在Linux中，超时以500ms为单位进行控制，每次判定超时重发的超时时间都是500ms的整数倍。其规律为：如果重发一次仍得不到应答，就等待2500ms后再进行重传，如果仍然得不到应答就等待4500ms后重传，依次类推，以指数形式递增，重传次数累计到一定次数后，TCP认为网络或对端主机出现异常，就会强行关闭连接。

• 5、连接管理机制 连接管理机制即TCP建立连接时的三次握手和断开连接时的四次挥手。 首先三次握手：

建立过程为： -（1）B首先建立传输控制块TCB，进入LISTEN（收听）状态，等待用户的连接请求。如有，则建立连接。（这个过程在套接字编程中为服务器端调用socket函数、bind函数和listen函数的过程）

• （2）A建立传输控制块TCB，然后向B发送连接请求报文段，报文段中首部的同步位SYN=1，同时选择一个序列号seq=x，TCP规定SYN报文段不携带数据，但要消耗一个序列号。然后A进入SYN-SENT（同步已发送）状态。（这个过程在套接字编程中为客户端调用socket函数和connect函数的过程）
• （3）B收到请求后，如同意建立连接，就向A发送确认报文段。此时SYN=1、ACK=1，确认号ack=x+1，同时选择一个序列号seq=y，这个报文也不携带数据，但要消耗一个序列号。然后B进入SYN-RCVD状态（同步收到）。
• （4）A收到B的确认后，还要向B发送确认。确认报文段的ACK=1，确认号ack=y+1，seq=x+1。TCP规定，ACK报文段可以携带数据，而如果不携带数据则不消耗序列号，此时下一个报文段的序列号仍为seq=x+1。这时，连接就建立成功了，A进入ESTABLISHED状态（已建立连接状态）。
• （5）当B收到A的确认后，也进入ESTABLISHED状态，此时就可以进行数据传输了。 当然，在进行三次握手时不是仅进行连接，可能还会进行一些后续操作所需要的信息交流。

四次挥手：

在连接释放时，连接的两方都要同意才能够释放成功（就像情侣分手一样，分手时两个人的事儿）。连接的双方都可以提出释放连接，这里假设A先提出释放连接，首先双方都处于ESTABLISHED状态。

• （1）当A的数据传送完后，就可以向其TCP发起连接释放了，此后停止再发送数据，主动关闭TCP连接。首先A向B发送一个FIN报文段，报文段首部FIN=1，序列号seq=u（u为最后传送的数据的序列号加1），然后A进入FIN-WAIT-1（终止等待1）状态。FIN报文段不能携带数据，但要消耗一个序列号。

• （2）B收到释放连接的报文段后即发出确认报文段，报文首部ACK=1，ack=u+1，seq=v（v等于B前面传送过的数据的序列号加1），然后B进入CLOSE-WAIT（关闭等待）状态。这时从A到B这个方向的连接就释放了，TCP连接就处于半关闭状态。（注意：此后A不能主动向B发送数据，但是A可以给B发送确认报文段，也就是说A仍要接收来自B的报文，因为从B到A这个方向的连接还没有关闭）

• （3）当A收到B的确认报文后，就进入FIN-WAIT-2（终止等待2）状态，等待B发出的连接释放报文段。

• （4）当B的数据发送完毕后，其应用进程就通知TCP释放连接。B向A发送FIN报文，报文段首部FIN=1，ack=u+1（重复发送上一次已经发送过的确认号），seq=w（w为B最后发送报文段的序列号加1）。然后B进入LAST-ACK（最后确认）状态，等待A的确认。

• （5）A在接收到B的连接释放报文后，必须进行确认。A向B发送的确认报文段中报文首部ACK=1，ack=w+1，seq=u+1。然后A进入TIME-WAIT（时间等待）状态（如果无差错，此状态时间为2MSL），注意，此时TCP连接还没有释放掉，必须经过TIME-WAIT设置的时间2MSL后，A撤销相应的传输控制块TCB，才进入CLOSED状态，结束了此次TCP连接。MSL叫做最长报文段寿命，RFC793建议设为2分钟，但在现在实际网络情况中，常用值有三种：30秒，1分钟，2分钟。必须要在A进入CLOSED状态后才能开始建立下一个新的连接。

• （6）B收到A的确认报文后，也进入CLOSED状态，撤销相应的传输控制块TCB，此时，TCP连接全部断开。 这样TCP四次挥手完成。

• 6、流量控制 接收端处理数据的速度是有限的，如果发送方发送数据的速度过快，导致接收端的缓冲区满，而发送方继续发送，就会造成丢包，继而引起丢包重传等一系列连锁反应。 因此TCP支持根据接收端的处理能力，来决定发送端的发送速度，这个机制叫做流量控制。 在TCP报文段首部中有一个16位窗口长度，当接收端接收到发送方的数据后，在应答报文ACK中就将自身缓冲区的剩余大小，放入16窗口大小中。这个大小随数据传输情况而变，窗口越大，网络吞吐量越高，而一旦接收方发现自身的缓冲区快满了，就将窗口设置为更小的值通知发送方。如果缓冲区满，就将窗口置为0，发送方收到后就不再发送数据，但是需要定期发送一个窗口探测数据段，使接收端把窗口大小告诉发送端。 其过程如下：

注意：窗口大小不受16位窗口大小限制，在TCP首部40字节选项中还包含一个窗口扩大因子M，实际窗口大小是窗口字段的值左移M位。

• 7、拥塞控制 流量控制解决了 两台主机之间因传送速率而可能引起的丢包问题，在一方面保证了TCP数据传送的可靠性。然而如果网络非常拥堵，此时再发送数据就会加重网络负担，那么发送的数据段很可能超过了最大生存时间也没有到达接收方，就会产生丢包问题。 为此TCP引入慢启动机制，先发出少量数据，就像探路一样，先摸清当前的网络拥堵状态后，再决定按照多大的速度传送数据。 此处引入一个拥塞窗口： 发送开始时定义拥塞窗口大小为1；每次收到一个ACK应答，拥塞窗口加1；而在每次发送数据时，发送窗口取拥塞窗口与接送段接收窗口最小者。 慢启动：在启动初期以指数增长方式增长；设置一个慢启动的阈值，当以指数增长达到阈值时就停止指数增长，按照线性增长方式增加；线性增长达到网络拥塞时立即“乘法减小”，拥塞窗口置回1，进行新一轮的“慢启动”，同时新一轮的阈值变为原来的一半。 “慢启动”机制可用图表示：

———————————————— 版权声明：引用自blog.csdn.net/xuzhangze/a…

TCP定时器有哪些

• 建立连接定时器：建立连接的过程中，在发送SYN时，会启动一个定时器（默认应该3秒），如果SYN包丢失，那么3秒以后会重新发送SYN包的（会启动一个新的定时器，设置为6秒超时），当然也不会一直没完没了的发SYN包，在/proc/sys/net/ipv4/tcp_syn_retries 可以设置到底要重新发送几次SYN包。
• 重传定时器：重传定时器在TCP发送数据时设定，在计时器超时后没有收到返回的确认ACK，发送端就会重新发送队列中需要重传的报文段。使用RTO重传计时器一般有如下规则：

1. 当TCP发送了位于发送队列最前端的报文段后就启动这个RTO计时器；
2. 如果队列为空则停止计时器，否则重启计时器；
3. 当计时器超时后，TCP会重传发送队列最前端的报文段；
4. 当一个或者多个报文段被累计确认后，这个或者这些报文段会被清除出队列

   重传计时器保证了接收端能够接收到丢失的报文段，继而保证了接收端交付给接收进程的数据始终的有序完整的。因为接收端永远不会把一个失序不完整的报文段交付给接收进程。

• 延迟应答定时器(delayed ACK timer)

   延迟应答也被成为捎带ACK， 这个定时器是在延迟应答的时候使用的。 为什么要延迟应答呢？ 延迟应答是为了提高网络传输的效率。

   举例说明，比如服务端收到客户端的数据后， 不是立刻回ACK给客户端， 而是等一段时间(一般最大200ms)，这样如果服务端要是有数据需要发给客户端，那么这个ACK就和服务端的数据一起发给客户端了， 这样比立即回给客户端一个ACK节省了一个数据包。

• 坚持定时器(persist timer)

   我们已经知道TCP通过让接收方指明希望从发送方接收的数据字节数（即窗口大小）来进行流量控制。如果窗口大小为 0会发生什么情况呢？这将有效地阻止发送方传送数据，直到窗口变为非0为止。接收端窗口变为非0后，就会发送一个确认ACK指明需要的报文段序号以及窗口大小。

   如果这个确认ACK丢失了，则双方就有可能因为等待对方而使连接终止：接收方等待接收数据（因为它已经向发送方通告了一个非0的窗口），而发送方在等待允许它继续发送数据的窗口更新。为防止这种死锁情况的发生，发送方使用一个坚持定时器 (persist timer)来周期性地向接收方查询，以便发现窗口是否已增大。这些从发送方发出的报文段称为窗口探查 (window probe)。

• 保活定时器(keepalive timer)

   在TCP连接建立的时候指定了SO_KEEPALIVE，保活定时器才会生效。如果客户端和服务端长时间没有数据交互，那么需要保活定时器来判断是否对端还活着，但是这个其实很不实用，因为默认是2小时没有数据交互才探测，时间实在是太长了。如果你真的要确认对端是否活着， 那么应该自己实现心跳包，而不是依赖于这个保活定时器。

• FIN_WAIT_2定时器(FIN_WAIT_2 timer)

   主动关闭的一端调用完close以后（即发FIN给被动关闭的一端， 并且收到其对FIN的确认ACK）则进入FIN_WAIT_2状态。如果这个时候因为网络突然断掉、被动关闭的一段宕机等原因，导致主动关闭的一端不能收到被动关闭的一端发来的FIN，主动关闭的一段总不能一直傻等着，占着资源不撒手吧？这个时候就需要FIN_WAIT_2定时器出马了， 如果在该定时器超时的时候，还是没收到被动关闭一端发来的FIN，那么不好意思， 不等了， 直接释放这个链接。FIN_WAIT_2定时器的时间可以从/proc/sys/net/ipv4/tcp_fin_timeout中查看和设置。

• TIME_WAIT定时器 (TIME_WAIT timer, 也叫2MSL timer)

   TIME_WAIT是主动关闭连接的一端最后进入的状态， 而不是直接变成CLOSED的状态， 为什么呢？第一个原因是万一被动关闭的一端在超时时间内没有收到最后一个ACK， 则会重发最后的FIN，2MSL（报文段最大生存时间）等待时间保证了重发的FIN会被主动关闭的一端收到且重新发送最后一个ACK；另外一个原因是在2MSL等待时间时，任何迟到的报文段会被接收并丢弃，防止老的TCP连接的包在新的TCP连接里面出现。不可避免的，在这个2MSL等待时间内，不会建立同样(源IP, 源端口，目的IP，目的端口)的连接。

nagle算法

• 当一个TCP连接中有在传数据（即已发送但未经确认的数据），小的报文段（长度小于SMSS）就不能被发送，直到所有的在传数据都收到ACK。并且，在收到ACK后，TCP需要收集这些小数据，将其整合到一个报文段中发送。该算法精妙之处是实现类自时钟控制：ACK返回越快，数据传输也越快。即RTT控制着发包速率
• 优点：减小了小包数量
• 缺点：增大了传输时延（在任一时刻只有一个包在传，只有一个方向上保持传输状态）

TCP粘包

• TCP粘包指发送方发送的若干包数据到达接收方时粘成一包，从接收缓冲区来看，后一包的头紧接着前一包的数据的尾
• 原因
  • 发送方：TCP默认采用nagle算法（干两件事，只有上一个分组得到确认，才会发送下一个分组。收集多个小分组，在一个确认到来时一起发送），这就造成了粘包问题
  • 接收方：TCP接收到数据包时，并不会马上交到应用层进行处理，或者说应用层并不会立即处理。实际上，TCP将接收到的数据包保存在接收缓存里，然后应用程序主动从缓存读取收到的分组。这样一来，如果TCP接收数据包到缓存的速度大于应用程序从缓存中读取数据包的速度，多个包就会被缓存，应用程序就有可能读取到多个首尾相接粘到一起的包。
• 什么时候需要处理粘包现象？
  • 如果发送方发送的多组数据本来就是同一块数据的不同部分，比如说一个文件被分成多个部分发送，这时当然不需要处理粘包现象
  • 如果多个分组毫不相干，甚至是并列关系，那么这个时候就一定要处理粘包现象了
• 如何处理粘包现象？
  • 发送方：对于发送方造成的粘包问题，可以通过关闭Nagle算法来解决，使用TCP_NODELAY选项来关闭算法。
  • 接收方：接收方没有办法来处理粘包现象，只能将问题交给应用层来处理。
  • 应用层：不仅能解决接收方的粘包问题，还可以解决发送方的粘包问题。解决办法：循环处理，应用程序从接收缓存中读取分组时，读完一条数据，就应该循环读取下一条数据，直到所有数据都被处理完成，但是如何判断每条数据的长度呢？
    • 格式化数据：每条数据有固定的格式（开始符，结束符），这种方法简单易行，但是选择开始符和结束符时一定要确保每条数据的内部不包含开始符和结束符。
    • 发送长度：发送每条数据时，将数据的长度一并发送，例如规定数据的前4位是数据的长度，应用层在处理时可以根据长度来判断每个分组的开始和结束位置。（如果设置长度而当前没收到这么多补0填充）
    • 发送端给每个数据包添加包首部，首部中应该至少包含数据包的长度，这样接收端在接收到数据后，通过读取包首部的长度字段，便知道每一个数据包的实际长度了。

http和tcp的区别

• http是超文本传输协议---应用层协议
• tcp是传输控制协议---传输层协议
• http承载于tcp之上，数据包在传输过程中，http被封装于tcp包中

什么是tcp四次挥手

在网络数据传输中，传输层协议断开连接的过程我们称为四次挥手

四次挥手的具体细节

1. 第一次挥手：Client将Fin置为1，发送序列号seq给Server，进入FIN_WAIT_1状态
2. 第二次挥手：Server收到FIN之后，发送一个ACK=1，acknowledge number=收到序列号+1，进入CLOSE_WAIT状态。此时客户端已经没有要发送的数据了，单扔可以接受服务器发来的数据
3. 第三次挥手：Server将FIN置1，发送一个序列号给Client，进入LAST_ACK状态
4. 第四次挥手：Client收到服务器的FIN后进入TIME_WAIT状态，接着将ACK置1，发送一个acknowledge number=收到序列号+1给Server，服务器收到后，确认acknowledge number后变为CLOSED状态，不再向客户端发送数据，客户端等待2*MSL（报文段最长寿命）时间后，也进入CLOSED状态。完成四次挥手

用现实理解tcp四次挥手的细节

• 四次挥手断开连接时因为要确定数据全部都传输完了

1. 客户端与服务器交谈结束后，客户要结束此次会话，和服务器说：我要关闭连接了
2. 服务端收到客户端的消息后：好的，我知道你要关闭连接了
3. 服务器也确定没什么话要和客户说了，服务器就对客户说，我也要关闭连接了
4. 客户收到服务器要关闭连接的消息后说：我收到你要关闭连接的消息了

为什么不能把服务器发送的ACK和FIN合并起来，变成三次挥手（CLOSE_WAIT状态的意义是什么）

因为服务器收到客户端断开连接的请求时，可能还有一些数据没有发送完，先回复ACK，表示接收到了断开连接的请求了。等到确定数据已经发送完毕后再发FIN，断开服务器到客户端的数据传送

如果第二次挥手时服务器的ACK没有送达客户端，会怎么样

客户端没有收到ACK确认的话，会重新发送FIN请求

客户端TIME_WAIT状态的意义是什么

第四次挥手时，客户端发送到服务器的ACK可能丢失，TIME_WAIT状态就是用来重发可能丢失的ACK报文的。如果Server没有收到ACK，就会重发FIN，如果CLIENT在2MSL的时间内收到FIN，就会重新发送ACK并再次等待2MSL，防止Server没有收到ACK而不断重发FIN。MSL(Maximum Segment Lifetime)，指一个片段在网络中最大的存活时间，2MSL就是一个发送和一个回复所需的最大时间。如果直到2MSL，Client都没有再次收到FIN，那么Client就会认为ACK已经被成功接收，则断开TCP连接

TCP报文头有哪些内容

端口号、序列号和确认号、数据偏移/首部长度、保留、控制位：URG、 ACK、PSH 、 RST 、 SYN、 FIN、窗口、校验和、紧急指针、选项和填充、数据部分

ARP协议知道么？

• APR协议完成了IP地址与物理地址的映射，每一个主机都设有一个ARP高速缓存，里面有所在的局域网上各主机和路由器IP地址到硬件地址的映射。当源主机要发送数据包到目的主机时，回先检查主机的ARP高速缓存中有没有目的主机的的MAC地址，如果有，就直接发送数据包到这个MAC地址，如果没有，就向所在地局域网发起一个ARP请求的广播包（会携带自己的ip到mac地址的映射），收到请求的主机检查自己的ip和目的主机的ip是否一致，如一致，则先保存源主机的映射到自己的ARP缓存，然后向源主机发送一个ARP响应数据包。源主机收到响应数据包后，先添加目的主机ip与mac的映射，再进行数据传送，如源主机一直没有响应则表示ARP查询失败
• 如果所要找的主机和源主机不在一个局域网上，通过ARP找到一个位于本局域网上的某个路由器的硬件地址，然后把分组发送到这个路由器，让这个路由器把分组转发到下一个网络，剩下的工作就由下一个网络去做

NAT是啥

• 用于解决内网中的主机和因特网上的主机通信。由NAT路由器将主机的本地Ip地址转换为全球ip地址，分为静态装换和动态NAT转换

Socket和Http的区别和使用场景

• Socket连接就是所谓的长连接，理论上客户端和服务器端一旦建立连接将不会主动断掉
• Socket使用场景：网络游戏、银行持续交付、直播、在线视频等
• Http连接就是所谓的短连接，即客户端向服务器端发送一次请求，服务器端响应后连接即会断开等待下次连接
• http适用场景：公司OA服务，互联网服务，电商，办公，网站等等

http协议使用什么协议实现的

• 负责传输的Ip协议：将各种数据包传送给对方
• 确保可靠性的TCP协议：提供可靠的字节流服务
• 负责域名解析的DNS服务：提供域名到Ip地址之间的解析服务

什么是http请求体？

• http请求体是我们请求数据时发送给服务器的数据
• http请求体由请求行、请求头、请求数据组成
• 注意get请求是没有请求体的

http的响应报文有哪些

• http的响应报文是服务器返回给我们的数据
• 响应报文包含状态行、响应首部字段、响应内容

http和https的区别

• https其实就是http加上加密处理+认证+完整性保护
• 区别
  1. https需要拿到ca证书（用钱买的）
  2. 端口不一样，http是80，https是443
  3. http是超文本传输协议，信息都是明文传输，而https是具有安全性的ssl加密传输协议
  4. http是无转态的不安全的，而https是由ssl+http协议构建的进行安全传输、身份认证的网络协议是安全的

https的工作原理

1. 浏览器向服务器的443端口发送请求，请求携带了浏览器支持的加密算法和哈希算法
2. 服务器收到请求，选择浏览器支持的加密算法和哈希算法
3. 服务器将数字证书返回给浏览器，这里的数字证书是向某个可靠机构申请的，也是可以自制的
4. 浏览器进入数字证书认证环节，这一部分是浏览器内置的TLS完成的
   1. 首先浏览器会从内置的证书列表中索引，找到服务器下发证书对应的机构，如果没有找到，此时会提示用户该证书是不是由权威机构颁发的，是不是可信任的。如果查到对应的机构，则取出该机构颁发的公钥
   2. 用机构的证书公钥解密得到的证书的内容和证书签名，内容包括网站的网址、网站的公钥、证书的有效期等。浏览器会先验证证书签名的合法性。签名通过后，浏览器验证证书记录的网址是否和当前网址是一致的，不一致会提示用户。如果网址一致会检查证书的有效期，证书过期了也会提示用户。这些都通过认证了，浏览器就可以安全使用证书中网站公钥了
   3. 浏览器会生成一个随机数R，并使用网站公钥对R进行加密
5. 浏览器将加密的R传送给服务器
6. 服务器用自己的私钥解密得到R
7. 服务器以R为密钥使用对称加密算法加密网页内容并传输给浏览器
8. 浏览器以R为密钥使用之前约定好的解密算法获取网页内容

一次完整的http请求经历几个步骤

1. 建立tcp连接
2. web浏览器向服务器发送请求行（web浏览器向web服务器发送请求命令，如GET /sample/hello.jsp HTTP/1.1）
3. web浏览器发送请求头（以头信息的形式向web服务器发送一些别的信息，之后浏览器会发送一个空白行通知服务器，他已经结束了头信息的发送）
4. web服务器应答（服务器会非客户端发送应答，HTTP/1.1 200 OK，应答的第一部分是协议的版本号和应答状态码）
5. web服务器发送应答头（服务器向客户端发送关于他自己的数据及被请求的文档）
6. web服务器向浏览器发送数据（服务端发送完头信息后，会发送一个空白行来表示头信息发送到此为结束，接着他就以content-type应答头信息所描述的格式发送用户所请求的实际数据）
7. web服务器关闭tcp连接

常用HTTP状态码是怎么分类的，有哪些常见的状态码

• HTTP状态码表示客户端HTTP请求的返回结果，标识服务器处理是否正常、表明请求出现的错误等
• 状态码类别
  • 1xx：指示信息-表示请求已接收，正在处理
  • 2xx：成功-表示请求已被成功接收、理解、接受
  • 3xx：重定向-要完成请求必须进行更进一步的操作
  • 4xx：客户端错误-请求有语法错误或请求无法实现
  • 5xx：服务端错误-服务器未能实现合法的请求
• 常见的状态码
  • 200： 请求被正常处理
  • 204： 请求被受理但没有资源可以返回
  • 206：客户端只是请求资源的一部分，服务器只对请求的部分资源执行GET方法，相应报文中通过Content-Range指定范围的资源。
  • 301： 永久性重定向
  • 302： 临时重定向
  • 303：与302状态码有相似功能，只是它希望客户端在请求一个URI的时候，能通过GET方法重定向到另一个URI上
  • 304： 发送附带条件的请求时，条件不满足时返回，与重定向无关
  • 307： 临时重定向，与302类似，只是强制要求使用POST方法
  • 400： 请求报文语法有误，服务器无法识别
  • 401： 请求需要认证
  • 403： 请求的对应资源禁止被访问
  • 404： 服务器无法找到对应资源
  • 500： 服务器内部错误
  • 503： 服务器正忙

http协议中有哪些请求方式

• GET：用于请求访问已经被URI（统一资源标识符）识别的资源，可以通过URL传 参给服务器
• POST：用于传输信息给服务器，主要功能与GET方法类似，但一般推荐使用POST 方式。
• PUT： 传输文件，报文主体中包含文件内容，保存到对应URI位置。
• HEAD：获得报文首部，与GET方法类似，只是不返回报文主体，一般用于验证URI是否有效。
• PATCH： 客户端向服务器传送的数据取代指定的文档的内容(部分取代)
• TRACE： 回显客户端请求服务器的原始请求报文，用于"回环"诊断
• DELETE： 删除文件，与PUT方法相反，删除对应URI位置的文件。
• OPTIONS： 查询相应URI支持的HTTP方法。

GET和POST方法的区别

• get重在从服务器上获取资源，post重在想服务器发送数据
• Get传输的数据量小，因为受url长度限制，但效率高，post可以传输大量数据，所以上传文件时只能用post
• get是不安全的，因为get请求发送数据都在url上，可见的，可能会泄露私密信息，如密码，post放在请求头上，是比get安全的

http版本对比

• 1.0：无状态无连接的应用层协议（浏览器的每次请求都需要与服务器建立一个tcp连接，服务器处理完成后立即断开的tcp连接，服务器也不跟踪每个客户端也不记录过去的状态）
• 1.1 ：
  • 默认持久连接节省通信量（即某一端不断开就一直连接），可以发送多次http请求。
  • 管线化：客户端可以同时发送多个http请求，而不是一个个等待响应
  • 断点续传原理
• 2.0 ：
  • 二进制分帧（采用二进制格式的编码将其封装）
  • 首部压缩（设置了专门的首部压缩设计的HPACK算法。）
  • 流量控制（设置了接收某个数据流的多少字节一些流量控制）
  • 多路复用（可以在共享TCP链接的基础上同时发送请求和响应）
  • 请求优先级（可以通过优化这些帧的交错和传输顺序进一步优化性能）
  • 服务器推送

Http与Https优缺点？

• 通信使用明文不加密，内容可能被窃听，也就是被抓包分析。
• 不验证通信方身份，可能遭到伪装
• 无法验证报文完整性，可能被篡改
• HTTPS就是HTTP加上加密处理（一般是SSL安全通信线路）+认证+完整性保护

http连续发送了两个请求，怎么确保该响应就是对应请求的内容

管线化技术支持：pipeLining是这样一种技术：在等待上一个请求响应的同时，发送下一个请求（pipeLining其实是把多个Http请求放到一个TCP连接中一一发送，在发送过程中不需要等待服务器对前一个请求的响应；只不过，服务器还是要按照发送请求的顺序处理请求，客户端还是要按照发送请求的顺序来接收响应）。

什么是对称加密与非对称加密

• 对称密钥加密是指加密和解密使用同一个密钥的方式，这种方式存在的最大问题就是密钥发送问题，即如何安全地将密钥发给对方；
• 非对称加密是指使用一对非对称密钥，即公钥和私钥，公钥可以随意发布，但私钥只有自己知道。发送密文的一方使用对方的公钥进行加密处理，对方接收到加密信息后，使用自己的私钥进行解密。 由于非对称加密的方式不需要发送用来解密的私钥，所以可以保证安全性；但是和对称加密比起来，非常的慢

浏览器输入URL到显示的过程

1. 浏览器查询DNS，获取域名对应的ip地址：具体过程包括浏览器搜索自身的DNS缓存、搜索操作系统的DNS缓存、读取本地的Host文件和向本地DNS服务器进行查询等。对于向本地DNS服务器进行查询，如果要查询的域名包含在本地配置区域资源中，则返回解析结果给客户机，完成域名解析（此解析具有权威性）；如果要查询的域名不由本地DNS服务器区域解析，但该服务器已缓存了此网址映射关系，则调用这个Ip地址映射，完成域名解析（此解析不具有权威性）。如果本地域名服务器并未缓存该网址的映射关系，那么将根据其设置发起递归查询或者迭代查询
2. 浏览器获得域名对应的ip地址后，浏览器向服务器请求建立连接，发起三次握手
3. TCP/IP连接建立起来后，浏览器向服务器发送http请求
4. 服务器接收到这个请求，并根据路径参数映射到特定的请求处理器进行处理，并将处理结果及相应的视图返回给浏览器
5. 浏览器解析并渲染视图，若遇到js文件、css文件及图片等静态资源的引用，则重复上述步骤并向服务器请求这些资源
6. 浏览器根据其请求到的资源、数据渲染页面，最终向用户呈现一个完整的页面

测试两台机器能够连通的命令，答ping，又问ping用什么协议实现

• Ping命令用ICMP实现的，ICMP是Internet控制消息协议，用于IP主机，路由器之间传递消息。控制消息是指网络通不通，主机是否可达，路由器是否可用等网络本身的消息，这些控制消息并不传输用户数据。

查看转发过程中经过哪些路由器的命令

• Tracert命令，跟踪路由的Tracert命令也是基于ICMP协议

cookie和session对于HTTP有什么用？

HTTP协议本身是无法判断用户身份。所以需要cookie或者session

什么是cookie

cookie是由Web服务器保存在用户浏览器上的文件（key-value格式），可以包含用户相关的信 息。客户端向服务器发起请求，就提取浏览器中的用户信息由http发送给服务器

什么是session

• session 是浏览器和服务器会话过程中，服务器会分配的一块储存空间给session。
• 服务器默认为客户浏览器的cookie中设置 sessionid，这个sessionid就和cookie对应，浏览器在向服务器请求过程中传输的cookie 包含 sessionid ，服务器根据传输cookie 中的 sessionid 获取出会话中存储的信息，然后确定会话的身份信息。

cookie与session区别

1. cookie数据存放在客户端上，安全性较差，session数据放在服务器上，安全性相对更高
2. 单个cookie保存的数据不能超过4K，session无此限制
3. session一定时间内保存在服务器上，当访问增多，占用服务器性能，考虑到服务器性能方面，应 当使用cookie。