网络协议层第一次握手：Client将标志位SYN置为1，随机产生一个值seq=J，并将该数据包发送给Server，Cli

tcp udp区别

	tcp	udp
有无连接	有连接	无连接
可靠性	可靠，确认重传机制	不可靠
速度	慢	快
顺序	保证顺序，滑动窗口	无顺序
单播/多播	点到点	一对一，一对多
面向字节流/报文	面向字节流	面向报文
报文头长度	长20字节	短8字节
拥塞控制	有拥塞控制，防止网络过载	没有拥塞控制
应用领域	时间要求不高，可靠性要求高，金融等	游戏视频等
应用层协议	http、https、ftp等	dhcp、dns协议等

如何理解udp面向报文：发送方的udp对应用程序交下来的报文再添加首部后就向下交付，udp对应用层交付下来的报文既不合并也不拆分，也就是说有多长，UDP就照样发送，即一次发送一个报文，所以是面向报文的
如何理解TCP是面向字节流的：TCP不保证接收方收到的数据块和发送方所发出的的数据块相等，但是保证发送和接收的字节流完全一样，所以是面向字节流的

tcp建立连接三次握手，断开四次

tcp标志位
SYN(synchronous建立联机)
ACK(acknowledgement 确认)
PSH(push传送)
FIN(finish结束)
RST(reset重置)
URG(urgent紧急)
Sequence number(顺序号码)
Acknowledge number(确认号码)

三次握手过程

第一次握手：Client将标志位SYN置为1，随机产生一个值seq=J，并将该数据包发送给Server，Client进入SYN_SENT状态，等待Server确认。

SYN：同步序列编号(Synchronize Sequence Numbers)

第二次握手：Server收到数据包后由标志位SYN=1知道Client请求建立连接，Server将标志位SYN和ACK都置为1，ack=J+1，随机产生一个值seq=K，并将该数据包发送给Client以确认连接请求，Server进入SYN_RCVD状态。

第三次握手：Client收到确认后，检查ack是否为J+1，ACK是否为1，如果正确则将标志位ACK置为1，ack=K+1，并将该数据包发送给Server，Server检查ack是否为K+1，ACK是否为1，如果正确则连接建立成功，Client和Server进入ESTABLISHED状态，完成三次握手，随后Client与Server之间可以开始传输数据了

为什么要三次握手？

谢希仁版《计算机网络》中的例子是这样的，“已失效的连接请求报文段”的产生在这样一种情况下：client发出的第一个连接请求报文段并没有丢失，而是在某个网络结点长时间的滞留了，以致延误到连接释放以后的某个时间才到达server。本来这是一个早已失效的报文段。但server收到此失效的连接请求报文段后，就误认为是client再次发出的一个新的连接请求。于是就向client发出确认报文段，同意建立连接。假设不采用“三次握手”，那么只要server发出确认，新的连接就建立了。由于现在client并没有发出建立连接的请求，因此不会理睬server的确认，也不会向server发送ack包。server却以为新的运输连接已经建立，并一直等待client发来数据。这样，server的很多资源就白白浪费掉了。采用“三次握手”的办法可以防止上述现象发生。例如刚才那种情况，client不会向server的确认发出确认。server由于收不到确认，就知道client并没有要求建立连接。在谢希仁著《计算机网络》第四版中讲“三次握手”的目的是“为了防止已失效的连接请求报文段突然又传送到了服务端，因而产生错误”

四次握手断开连接

1.第一次挥手：Client发送一个FIN，用来关闭Client到Server的数据传送，Client进入FIN_WAIT_1状态。

2.第二次挥手：Server收到FIN后，发送一个ACK给Client，确认序号为收到序号+1（与SYN相同，一个FIN占用一个序号），Server进入CLOSE_WAIT状态。

3.第三次挥手：Server发送一个FIN，用来关闭Server到Client的数据传送，Server进入LAST_ACK状态。

4.第四次挥手：Client收到FIN后，Client发送一个ACK给Server，接着进入TIME_WAIT状态，确认序号为收到序号+1， Server进入CLOSED状态，完成四次挥手。

time_wait状态主要做了什么

1.假设客户端主动断开连接，向服务器发送fin报文，这个报文主要告诉服务器客户端已经没有数据想要传给服务器，但是服务器你如果有数据没传输完的话，先不用断开socket连接，可以继续发你的数据，先给客户端发ack报文。2.服务器收到报文，看了fin的报文，给客户端发了ack报文，告诉客户端服务器已经收到了消息，但我还有事没做完，让客户端等会。3.这时候客户端进入FIN_WAIT状态，即等待服务器给他发fin报文。当服务器确定传输的数据都发完了，再向客户端发送fin报文。告诉客户端我已经传输完所有数据了，可以关闭socket连接。4.客户端收到fin报文，就知道socket要断开连接了，向服务器发送ack报文，但客户端不确定这个报文是否传到服务器了，于是进入Time_wait状态，如果服务器没有收到ack报文则会进行fin报文重传，如果客户端等待30s没有收到消息说明连接服务器端已经关闭了，客户端可以安心关闭了。这样tcp就断开了。在TIME_WAIT状态中，如果TCP client端最后一次发送的ACK丢失了，它将重新发送。TIME_WAIT状态中所需要的时间是依赖于实现方法的。典型的值为30秒、1分钟和2分钟。等待之后连接正式关闭，并且所有的资源(包括端口号)都被释放。如果Client直接CLOSED了，那么由于IP协议的不可靠性或者是其它网络原因，导致Server没有收到Client最后回复的ACK。那么Server就会在超时之后继续发送FIN，此时由于Client已经CLOSED了，就找不到与重发的FIN对应的连接，最后Server就会收到RST而不是ACK，Server就会以为是连接错误把问题报告给高层。这样的情况虽然不会造成数据丢失，但是却导致TCP协议不符合可靠连接的要求。所以，Client不是直接进入CLOSED，而是要保持TIME_WAIT，当再次收到FIN的时候，能够保证对方收到ACK，最后正确的关闭连接

为什么连接的时候是三次握手，关闭的时候却是四次握手？

答：因为当Server端收到Client端的SYN连接请求报文后，可以直接发送SYN+ACK报文。其中ACK报文是用来应答的，SYN报文是用来同步建立联机的（确认和建立联机可以一起发）。但是关闭连接时，当Server端收到FIN报文时，很可能并不会立即关闭SOCKET，所以只能先回复一个ACK报文，告诉Client端，"你发的FIN报文我收到了"。只有等到我Server端所有的报文都发送完了，我才能发送FIN报文，因此不能一起发送。故需要四步握手

osi7层协议、5层协议、4层协议

讲解计算机网络的很好的视频： www.warriorsofthe.net/movie.html

mac地址（硬件地址）和ip地址（软件地址）联系和区别？

IP地址是放在IP数据报的首部，硬件地址放在MAC帧的首部。在网络层及网络层以上使用
的是IP地址，数据链路层及以下使用的是硬件地址，当IP数据报放入数据链路层的MAC帧
中以后，整个IP数据报就成为MAC帧的数据，因而在数据链路层是看不见IP地址的。
另外IP数据报向下传输时，通过ARP协议找到IP地址对应的硬件地址，封装在MAC帧首部

	IP地址	MAC地址
可见协议层	网络层及以上	数据链路层及以下
传输是否可变	整个传输过程中，源IP，目的IP始终不变	传输过程源MAC地址，目的MAC地址根据当前传输主机或路由器的MAC地址变化

数据传输过程详解

IP地址有网络号和主机号组成，网络号相同的所有主机可以成为属于同一个网络，不同网络的主机通过路由器连接，所以路由器有两个IP地址现在A中一个应用向B中一个应用传输数据，A中有5层协议，应用层封装数据给传输层，传输层会把端口信息封装在数据中往下传，到网络层把源IP，目的IP封装进去，再往下数据链路层会将IP对应的Mac地址放在Mac帧首部，Mac帧里有源Mac地址和目的Mac地址，目的Mac地址就是当前要去的主机或者路由器，根据这个地址就开始在网络链路上传输了，中间经过路由器，路由器从下网上把数据剥开到网络层查看目的IP，判断下一跳该是哪一个主机，然后找到对应Mac地址，在往下封装数据，就这样一直传输，直到最后目的主机，从下往上剥开数据直到应用层，这样数据就传输过去了

散知识点

网络层不提供可靠传输，运输层可以提供可靠传输        
路由器仅根据目的主机的**网络号**转发分组（而不考虑目的主机号），路由表里面是[
目的网络 下一跳地址]，这样路由表里面的项目数就大量减少，节省存储空间和查找时间   
当一个主机同时连接在两个网络上，该主机就必须有两个相应的IP地址，网络号必须是不
同的      
具有不同网络号的局域网必须使用路由器互连        
同一个局域网上的主机或路由器的IP地址中的网络号必须是一样的      
网络层使用的是IP地址，但实际网络的链路上传送数据帧时，还是要使用该网络的硬件地址
网络链路上传送的帧是按照硬件地址找到目的主机的，为什么还需要使用抽象的IP地址，
不直接使用硬件地址呢？（世界上有各种各样的网络，使用不同的硬件地址，如果只使用
硬件地址，要进行非常复杂的硬件地址转换工作，但IP编址把这个问题解决了，链接到互
联网上的主机只需要有一个唯一的IP地址，他们之间的通信就像是在同一个网络上一样方
便，可以想象每次判断目的IP地址然后直到下一步哪里传，如果只是硬件地址，怎么知道
下一步该给谁，难道全部都广播问谁是这个硬件地址吗？）

当网络边缘部分中的两台主机使用网络核心部分的功能进行端到端通信时，只有主机的协
议栈有**运输层**，而网络核心部分中的路由器在转发分组时只用到**下三层**的功能，
如下图所示

ARP地址解析协议

每一台主机都设有一个ARP高速缓存（ARPcache），里面有本局域网上的各主机和路由器的
IP地址到硬件地址的映射表，有一些本局域网主机信息没有出现在映射表中，该主机会发
一个**广播**，广播内容是“我的IP地址是***，MAC地址是****，我想知道IP地址是***的
主机的MAC地址”，无关主机收到广播会丢弃，相关主机收到会把发送广播主机的信息存储
到自己的ARP映射表里，然后发送**单播**消息到查询主机

需要注意的是，ARP是解决同一个局域网上的主机或者路由器的IP地址和硬件地址的映射问题，当源主机需要将IP数据报往数据链路层传输，判断属于同一网络，才会使用ARP查询他的硬件地址，如果不是同一个网络会查询路由器的硬件地址，将数据传给路由器，路由器拿到数据判断数据下一步怎么传
图上说明的是ARP使用的四中典型情况

流量控制和拥塞控制

	流量控制	拥塞控制
含义	抑制发送端发送数据的速率，以便使接收者来得及接收	防止过多的数据注入到网络中，避免出现网络负载过大的情况
实现方法	滑动窗口	慢开始、拥塞避免快重传、快恢复
区别	点对点通信量的控制，发送方和接收方有关	整个网络，全局性的过程

如果发送者发送数据过快，接收者来不及接收，那么就会有分组丢失。为了避免分组丢失，控制发送者的发送速度，使得接收者来得及接收，这就是流量控制。流量控制根本目的是防止分组丢失，它是构成TCP可靠性的一方面。
由滑动窗口协议（连续ARQ协议）实现。滑动窗口协议既保证了分组无差错、有序接收，也实现了流量控制。主要的方式就是接收方返回的 ACK 中会包含自己的接收窗口的大小，并且利用大小来控制发送方的数据发送。
流量控制引发的死锁？怎么避免死锁的发生？
当发送者收到了一个窗口为0的应答，发送者便停止发送，等待接收者的下一个应答。但是如果这个窗口不为0的应答在传输过程丢失，发送者一直等待下去，而接收者以为发送者已经收到该应答，等待接收新数据，这样双方就相互等待，从而产生死锁。
为了避免流量控制引发的死锁，TCP使用了持续计时器。每当发送者收到一个零窗口的应答后就启动该计时器。时间一到便主动发送报文询问接收者的窗口大小。若接收者仍然返回零窗口，则重置该计时器继续等待；若窗口不为0，则表示应答报文丢失了，此时重置发送窗口后开始发送，这样就避免了死锁的产生。