计算机网络常见知识点

内容会持续更新，有错误的地方欢迎指正，谢谢!

0.TCP连接有多少种状态？怎样查看TCP连接状态

总共有11种状态，如下图。一个正常的TCP连接，都会有三个阶段：三次握手、数据传送、四次挥手。

三次握手中涉及到4个状态；四次挥手中涉及到6+1个状态，最后加的那个1是CLOSING状态，很少见，图中也没有。

如何查看：netstat -nat|awk '{print $6}'|sort|uniq -c|sort -rn

输出结果如下：

150 ESTABLISHED
 22 TIME_WAIT
 15 LAST_ACK
 8  CLOSE_WAIT
 4  LISTEN

右上可看出，当前网络下TCP连接处于ESTABLISHED、TIME_WAIT、LAST_ACK、CLOSE_WAIT、LISTEN状态的分别有150、22、15、8、4个。 这些都是TCP连接最常见的几种状态。
其中，常用的三个状态是：ESTABLISHED 表示正在通信，TIME_WAIT 表示主动关闭，CLOSE_WAIT 表示被动关闭。

1.三次握手与四次挥手

（1）序号：seq序号，发起方发送数据时对此进行标记。
（2）确认序号：ack序号，只有标志位ACK为1时，确认序号才有效，ack=seq+1。
（3）标志位：共6个：

1. URG：紧急指针（urgent pointer）有效。
2. ACK：确认序号有效。
3. PSH：接收方应该尽快将这个报文交给应用层。
4. RST：重置连接。
5. SYN：发起一个新连接。
6. FIN：释放一个连接。

(1) 三次握手(我要和你建立链接，你真的要和我建立链接么，我真的要和你建立链接，成功！

SYN：发起一个新连接。将标志位SYN置为1
seq： 序号。随机产生一个值seq=J
ACK：确认序号有效。将标志位SYN置为1
ack： 确认序号。等于seq+1

(2) 四次挥手(我要和你断开链接；好的，断吧。我也要和你断开链接；好的，断吧。

FIN释放一个连接。seq为M。
ACK=1。ack=seq+1。
FIN释放一个连接。seq为N。
ACK=1。ack=seq+1。

下图有两个错误：第二次传输没加ACK=1 ;最后一次传输ack=N+1。

2.为什么TCP链接需要三次握手，两次不可以么？

客户端发出的连接请求报文并未丢失，而是在某个网络节点长时间滞留了，以致延误到链接释放以后的某个时间才到达Server。
这时，Server误以为这是Client发出的一个新的链接请求，于是就向客户端发送确认数据包，那么只要Server发出确认数据包，由于没有第三次握手，所以新的链接就建立了。由于client此时并未发出建立链接的请求，所以其不会理睬Server的确认，也不与Server通信；而这时Server一直在等待Client的请求，这样Server就白白浪费了一定的资源。
若采用“三次握手”，在这种情况下，由于Server端没有收到来自客户端的确认，则就会知道Client并没有要求建立请求，就不会建立链接。

3.有哪些应用层协议是基于TCP的，哪些是基于UDP的

TCP ：FTP、HTTP、Telnet、SMTP、POP3、HTTPS
UDP：DNS、SNMP、NFS

4.TCP与UDP的区别

TCP提供一种面向连接的、可靠的字节流服务。其中，面向连接意味着两个使用TCP的应用（通常是一个客户和一个服务器）在彼此交换数据之前必须先建立一个TCP连接。

UDP不属于连接型协议，因而具有资源消耗小，处理速度快的优点，所以通常音频、视频和普通数据在传送时使用UDP较多，因为它们即使偶尔丢失一两个数据包，也不会对接收结果产生太大影响。比如QQ就是使用的UDP协议。

传输控制协议TCP (Transmission Control Protocol)和用户数据报协议UDP(User Datagram Protocol)都属于传输层协议，它们之间的区别包括：

1. TCP是面向连接的，UDP是无连接的；
2. TCP是可靠的，UDP是不可靠的；
3. TCP只支持点对点通信，UDP支持一对一、一对多、多对一、多对多的通信模式；
4. TCP是面向字节流的，UDP是面向报文的；
5. TCP有拥塞控制机制；UDP没有拥塞控制，适合媒体通信；
6. TCP首部开销(20个字节)比UDP的首部开销(8个字节)要大；

流式套接字：是以TCP协议为代表的一类套接字，它表示数据以流的形式存在，上一个数据流与下一个数据流没有一个明显的分界线，也就是说你连续发来两个包，接受端可能只接受到一个，需要自己区分包的边界。

数据报套接字：是以UDP为代表，表明数据报与数据报之间有明显的分界线，发送方发送几个包，接受端就能接受到几个包，但网络传输过程会丢包。

5.TCP粘包的原因和如果不粘包

TCP粘包是指发送方发送的若干包数据到接收方接收时粘成一包，从接收缓冲区看，后一包数据的头紧接着前一包数据的尾。

为什么出现粘包现象？

1. 发送方原因
   我们知道，TCP默认使用Nagle算法。而Nagle算法会收集多个小分组，在一个确认到来时一起发送。所以，正是Nagle算法造成了发送方有可能造成粘包现象。
2. 接收方原因
   TCP接收到分组时，并不会立刻送至应用层处理，或者说，应用层并不一定会立即处理；实际上，TCP将收到的分组保存至接收缓存里，然后应用程序主动从缓存里读收到的分组。这样一来，如果TCP接收分组的速度大于应用程序读分组的速度，多个包就会被存至缓存，应用程序读时，就会读到多个首尾相接粘到一起的包。

解决方法：（主要从发送端来解决问题）

1. 发送端给每个数据包添加包首部，首部中应该至少包含数据包的长度。
2. 发送端将每个数据包封装为固定长度（不够的可以通过补0填充），这样接收端每次从接收缓冲区中读取固定长度的数据就可以把数据包拆分开了。
3. 发送端可以在数据包之间设置边界，如添加特殊符号。

6.UDP丢包的原因和如何不丢包

原因和对应的方法：

1. 接收端处理时间过长导致丢包，对于这种情况可以修改接收端，将包接收后存入一个缓冲区。
2. 发送的包巨大丢包，这种情况需要切割成小包再逐个send。
3. 发送的包较大，超过接受者缓存导致丢包，这种情况可以设置socket接收缓冲，以前“我”把接收缓冲设置成64K就解决了。
4. 发送的包频率太快，这种情况也有时可以通过设置socket接收缓冲解决，但有时解决不了，所以在发送频率过快的时候还是考虑sleep一下吧。
5. 局域网内不丢包，公网上丢包，这种情况“我”也是通过切割小包并sleep发送解决的。

如果用上述几个方法都解决不了，还有这个几个方法：

1. 多线程：在单线程的版本中，当接收完毕后便将数据写入到文件中，这个操作很耗费时间，当有新的数据过来时，程序依然在执行写入操作，来不及接受新过来的数据，因此造成丢包。开辟了一个新的线程负责将数据写入到文件，原来的线程只负责接收数据，两个线程之间用事件（Event）来同步。
2. 要么减小流量
3. 要么换TCP协议传输
4. 要么做丢包重传的工作。

7.网络游戏采用的是TCP协议还是UDP协议？

看你要做什么游戏
如果是由客户端间歇性的发起无状态的查询，并且偶尔发生延迟是可以容忍，那么使用HTTP/HTTPS吧。
如果客户端和服务器都可以独立发包，但是偶尔发生延迟可以容忍（比如：在线的纸牌游戏，许多MMO类的游戏），那么使用TCP吧。
如果客户端和服务器都可以独立发包，而且无法忍受延迟（比如：大多数的多人动作类、MOBA类、一些MMO类游戏），那么使用UDP吧。

可以容忍延迟并且有很好的屏蔽延迟的设计，如纸牌类和MMO，用TCP
不能容忍延迟，如DOTA类和动作类，用UDP
事实上，还是TCP在游戏中用的多，因为它可靠。

8.Http和Https的区别

Http和Https都是建立在TCP之上的协议。Http协议运行在TCP之上，明文传输，客户端与服务器端都无法验证对方的身份；Https运行于SSL上，SSL运行于TCP之上，是添加了加密和认证机制的HTTP。

二者之间存在如下不同：

1. 端口不同：Http与Https使用不同的连接方式，用的端口也不一样，前者是80，后者是443；
2. 资源消耗不同：和HTTP通信相比，Https通信会由于加减密处理消耗更多的CPU和内存资源；
3. 钱的开销：Https通信需要证书，而证书一般需要向认证机构购买；
4. Https的加密机制是一种共享密钥加密和公开密钥加密并用的混合加密机制。

9.HTTP常见常见状态码及原因短语

400：Bad Request,请求有语法问题
403：拒绝请求
404：客户端所访问的页面不存在

500 ：服务器内部错误

10.长连接和短连接

HTTP的长连接和短连接本质上是TCP长连接和短连接。
长连接：能保持长时间连接特性；
短连接：客户端和服务器每次传输数据都要建立一次连接，任务结束就中断连接。

11.套接字socket

TCP/IP协议族包括运输层、网络层、链路层，而Socket所在位置如图，Socket是应用层与TCP/IP协议族通信的中间抽象层，它是一组网络通信接口，应用层通过调用这些接口实现发送和接收数据。
指定了IP和端口，Socket就变成了独一无二的”电话号码“了，两个”电话号码“就可以互相传送数据了。

参考

【1】计算机网络面试问题集锦
http://blog.csdn.net/justloveyou_/article/details/78303617
【2】UDP丢包原因
http://www.cnblogs.com/mengyan/archive/2012/10/04/2711340.html