网络协议层

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，则表示应答报文丢失了，此时重置发送窗口后开始发送，这样就避免了死锁的产生。