【网络基础】TCP/UDP及网络协议

1，TCP和UDP区别

TCP协议面向连接的协议，提供稳定的双向通信，需要经过“三次握手”才能建立连接；为了提供稳定的数据传输功能，提供了超时重传机制，具有较高的稳定性。
UDP是无连接的，提供不稳定的单向通信功能，当然UDP也可以实现双向通信功能。虽然效率更高，但不能保证数据一定能够正确传输，尤其在网络拥塞的情况下。

1）区别

区别	TCP	UDP
连接	面向连接，如打电话要先拨号建立连接	无连接，直接发送数据不需要提取建立连接
可靠性	可靠；无差错，不丢失，不重复，且按序到达	不可靠；有可能出错、丢数据、无序
拥塞控制	有	没有。 如果网络拥塞不会降低发送速率。 如IP电话，实时视频会议等
内容	面向字节流。 从发送缓存中取出部分或者全部字节，并添加首部作为TCP报文发送	面向报文。 直接数据+头部进行转发。
交互通信	点到点	一对一，一对多，多对一和多对多
首部报文开销	20字节	8字节
通信信道	全双工的可靠信道	不可靠信道
报文长度	没有限制，由双方缓存决定	64k
缓冲区		没有有发送缓冲区，直接丢os内核，所以发送很快；有接收缓冲区，不保证接收顺序，缓冲区满了会丢数据。

1>TCP报文

TCP报文 = 首部（20个字节） + 数据载荷

首部格式：

首部	大小（bit)	说明	备注
源端口	16	标识发送tcp报文的应用进程；
目的端口	16	标识接收tcp报文的应用进程；
序号	32	用于对字节流进行编号；	如序号为 301，表示第一个字节的编号为 301，如果携带的数据长度为 100 字节，那么下一个报文段的序号应为 401。
确认号	32	期望收到的下一个报文段的序号。	序号和确认号保证了数据的可靠性。
数据偏移	4	首部长度，指的是数据部分距离报文段起始处的偏移量。
保留	6		为未来新功能留的
URG	1	表示紧急指针是否有效；
ACK	1	ACK=1表示确认序号有效，否则无效；	TCP 规定，在连接建立后所有传送的报文段都必须把 ACK 置 1。
PSH	1	表示提醒接收端应用程序立刻从TCP接收缓冲区里面把数据读走；
RST	1	表示对方要求重新建立连接，我们把表示为RST标识的称之为复位报文段；
SYN	1	表示请求建立连接，我们把SYN标识的段叫做请求同步报文段；	当 SYN=1，ACK=0 时表示这是一个连接请求报文段。若对方同意建立连接，则响应报文中 SYN=1，ACK=1。
FIN	1	表示本段要进行关闭了，我们把表示为FIN结束标识的段称之为结束报文段；	用来释放一个连接，当 FIN=1 时，表示此报文段的发送方的数据已发送完毕，并要求释放连接。
窗口	16	窗口值作为接收方让发送方设置其发送窗口的依据。之所以要有这个限制，是因为接收方的数据缓存空间是有限的。
校验和	16		校验不通过表示数据、头部有问题
紧急指针	16	标识紧急数据
选项	长度可变

2>UDP报文

UDP报文（最大64k）= 首部（8个字节） + 数据（明文）
1. 端口：都是2字节，2^16个端口：0-65535；
2. UDP报文长度：2字节，最大支持2^16个字节即64k；
超过会丢失数据。应用层数据包长度（UDP载荷）=UDP报文长度-8；
如果数据长度很长超过64k，可以写拆包组包的代码，但是复杂度较高。直接使用TCP，没有长度限制。
3. UDP校验和：判断传输过程中0 1bit刘是否由翻转错误（光信号电信号的高频表示1、低频表示0）
校验和：通过不一定表示数据准确；不通过数据一定错误。

2，TCP三次握手（three-way handshake）和四次分手

TCP用三次握手（three-way handshake）过程创建一个连接，使用四次分手 关闭一个连接。因为TCP是全双工模式，所以四次分手的目的就是为了可靠地关闭连接。
三次握手与四次分手的流程如下所示：连接状态说明

1）两个序号和三个标志位：

①序号

seq序号，占32位，用来标识从TCP源端向目的端发送的字节流，发起方发送数据时对此进行标记。

②确认序号

ack序号，占32位，只有ACK标志位为1时，确认序号字段才有效，ack=seq+1。
确认方ack=发起方req+1，两端配对。
###③标志位：共6个，即URG、ACK、PSH、RST、SYN、FIN等，具体含义如下：
（A）URG：紧急指针（urgent pointer）有效。
（B）ACK：确认序号有效。
（C）PSH：接收方应该尽快将这个报文交给应用层。
（D）RST：重置连接。
（E）SYN：发起一个新连接。
（F）FIN：释放一个连接。表示已经没有数据 需要发送了。

2）三次握手

①第一次握手：建立连接。

客户端发送连接请求报文段，将SYN位置为1，Sequence Number为x；然后，客户端进入SYN_SEND状态，等待服务器的确认；

②第二次握手：服务器收到SYN报文段。

服务器收到客户端的SYN报文段，需要对这个SYN报文段进行确认，设置Acknowledgment Number为x+1(Sequence Number+1)；同时，自己自己还要发送SYN请求信息，将SYN位置为1，Sequence Number为y；服务器端将上述所有信息放到一个报文段（即SYN+ACK报文段）中，一并发送给客户端，此时服务器进入SYN_RECV状态；

③第三次握手：客户端收到服务器的SYN+ACK报文段。

然后将Acknowledgment Number设置为y+1，向服务器发送ACK报文段，这个报文段发送完毕以后，客户端和服务器端都进入ESTABLISHED状态（已建立状态），完成TCP三次握手。 完成了三次握手，客户端和服务器端就可以开始传送数据。

④第三次握手的必要性

三次握手可以保证任何一次握手的失败都是可感知的，不会浪费资源。
否则，对于两次握手：A发送建立连接，B确认后就建立连接；在网络延迟的情况下，A第一次发送建立连接，B未响应，A第二次又发送建立连接，B建立连接。传输完成后关闭连接，当A第一次延迟的建立连接请求发送到B时，B建立连接，并且一直等待A发送数据，但对于A来说，连接已经关闭了。这样就造就了B一直在等待发送数据。
对于三次握手，A请求建立连接，B建立连接，A确认建立连接。A如果长时间未确认建立连接，B就会关闭连接。

⑤为什么不是四次握手

如果四次，那么就造成了浪费，因为在三次结束之后，就已经可以保证A可以给B发信息，A可以收到B的信息； B可以给A发信息，B可以收到A的信息。

⑥握手失败

第一次握手A发送SYN传输失败，A,B都不会申请资源，连接失败。如果一段时间内发出多个SYN连接请求，那么A只会接受它最后发送的那个SYN的SYN+ACK回应，忽略其他回应全部回应，B中多申请的资源也会释放

第二次握手B发送SYN+ACK传输失败，A不会申请资源，B申请了资源，但收不到A的ACK，过一段时间释放资源。如果是收到了多个A的SYN请求，B都会回复SYN+ACK，但A只会承认其中它最早发送的那个SYN的回应，并回复最后一次握手的ACK

第三次握手ACK传输失败，B没有收到ACK，释放资源，对于后序的A的传输数据返回RST。实际上B会因为没有收到A的ACK会多次发送SYN+ACK，次数是可以设置的，如果最后还是没有收到A的ACK，则释放资源，对A的数据传输返回RST

3）四次分手

收到一个FIN只是意味着这一方向上没有数据流动了，即不会再收到数据了，但是在这个TCP连接上仍然能够发送数据，直到这一方向也发送了FIN。

①第一次分手：表示主机1没有数据要发送给主机2了。

主机1（可以使客户端，也可以是服务器端），设置Sequence Number和Acknowledgment Number，向主机2发送一个FIN报文段；此时，主机1进入FIN_WAIT_1状态；

②第二次分手：主机2告诉主机1，我“同意”你的关闭请求。

主机2收到了主机1发送的FIN报文段，向主机1回一个ACK报文段，Acknowledgment Number为Sequence Number加1；主机1进入FIN_WAIT_2状态；主机2告诉主机1，我“同意”你的关闭请求；

③第三次分手：请求关闭。

主机2向主机1发送FIN报文段，请求关闭连接，同时主机2进入LAST_ACK状态；

④第四次分手：正常关闭。

主机1收到主机2发送的FIN报文段，向主机2发送ACK报文段，然后主机1进入TIME_WAIT状态；主机2收到主机1的ACK报文段以后，就关闭连接；此时，主机1等待2MSL后依然没有收到回复，则证明Server端已正常关闭，那好，主机1也可以关闭连接了。

⑤为什么分手比握手多一次

A给B发送FIN报文段，表示A没有数据发给B，但是B可能还有数据发给A。所以需要多确认一次。

3，TCP如何保证数据传输的可靠性？

1）确认和重传

接收方收到报文后就会进行确认，发送方一段时间没有收到确认就会重传。（见TCP重传机制）

2）数据校验

数据合理分片与排序，TCP会对数据进行分片，接收方会缓存为按序到达的数据，重新排序后再提交给应用层。

3）流程控制

当接收方来不及接收发送的数据时，则会提示发送方降低发送的速度，防止包丢失。

4）拥塞控制

当网络发生拥塞时，减少数据的发送。

4，TCP重传机制

传输过程中发生丢包，则需要使用重传机制。

1）超时重传机制（RTO）

在请求包发出去的时候，开启一个计时器，当计时器达到时间之后，没有收到ACK，就进行重发请求的操作，一直重发直到达到重发上限次数或者收到ACK。
例如：接收端给发送端的Ack确认只会确认最后一个连续的包，比如，发送端发了1,2,3,4,5一共五份数据，接收端收到了1，2，于是回ack 3，然后收到了4（注意此时3没收到），此时的TCP会怎么办？等待发送端的ACK 3，直到超时后，就会再发送3。
面临问题，重传是重传#3呢还是重传#3，#4，#5呢？

2）快速重传机制（Fast Recovery）

当接收方收到的数据包是不正常的序列号，那么接收方会重复把应该收到的那一条ACK重复发送，这个时候，如果发送方收到连续3条的同一个序列号的ACK，那么就会启动快速重传机制，把这个ACK对应的发送包重新发送一次。
例如：如果发送方发出了1，2，3，4，5份数据，第一份先到送了，于是就ack回2，结果2因为某些原因没收到，3到达了，于是还是ack回2，后面的4和5都到了，但是还是ack回2，因为2还是没有收到，于是发送端收到了三个ack=2的确认，知道了2还没有到，于是就马上重转2。然后，接收端收到了2，此时因为3，4，5都收到了，于是ack回6。
同样面临问题：是重传#2呢还是重传#2，#3，#4，#5呢？

①不启用sack的reno式重传

②sack重传

5，TCP阻塞

1）慢启动

当一个连接连接上网络的时候，并不应该一次向网络中就发送大量的数据包，否则的话，如果网络链路状况不是很好的情况，这些网络包可能会加重网络拥堵的情况。所以最初TCP连接建立之后，发送网络包的大小是逐渐增长的，最开始是1个最大报文大小，然后是指数级增长。这个就是慢启动机制。

但是到了一个数值，就不能再进行指数增长了，这个时候，网络包增长就从指数增长改成线性增长，就是一次增加一个MSS。这个就是拥塞避免阶段。

2）Nagle算法

如果每个网络传输都只传输一个小包，会浪费资源，增加拥堵。糊涂窗口综合症就是发送方和接收方糊里糊涂达成的协商是传送小包。

为了解决这个问题，很多方法应运而生，Nagle算法就是其中一个方法。

Nagle算法规定了，发送方网络链路上一个连接只能有一个未获得ACK的请求包。这个就意味着，发送方只有等待上一个请求的ACK回来之后才能发送下一个请求，这样两个请求过程中间，发送方的缓存区就存储了足够滑动窗口大小的包进行传递，这样就有效避免了大量的小包产生。

3）Cork算法

另外一种解决糊涂窗口综合症的方法就是Cork算法。这个算法比Nagle算法更激进一些，直接计算出一个值，当发送方的滑动窗口大小小于这个值的时候，不进行数据包的发送。这样这个算法就能有效直接杜绝小包的出现了。当然可能会导致数据有一定的延迟性了。

Nagle和Cork算法都是在发送方进行控制，两个算法的着重点不同，Cork算法着重点在于避免小包，更多是端到端的优化。Nagle算法则是为了提高网络的利用率。

4）延迟ACK

延迟ACK算法是从接收方防止糊涂窗口综合症。
接收方并不是收到请求之后立刻发送ACK，而是开启一个计时器，等到计时器结束的时候，才发送ACK。或者是接收方在需要回发送请求的时候，顺带着把上个请求的ACK发送回去了。这个机制如果配合Nagle算法，能让连接的滑动窗口达到一个预期的比较好的值。

6，网络协议

1）OSI体系（Open System Interconnect，OSI参考模型）

1. 通信子网（局域网）一般只包含最低的三层甚至两层（物理层、数据链路层、网络层）。
2. 层对层通信，如果路由器在设备A的网络层和设备B之间的网络层之间通信；上层不干预下一层通信，故2个设备的物理层和数据链路层协议可以不同。
3. 每一层为上层提供服务。

层级	OSI层	作用	举例（送快递为例）	协议
7	应用层	为用户提供服务	用户	DHCP · DNS · FTP · Gopher · HTTP · IMAP4 · IRC · NNTP · XMPP · POP3 · SIP · SMTP SNMP · SSH · TELNET · RPC · RTCP · RTP ·RTSP · SDP · SOAP · GTP · STUN · NTP · SSDP
6	表示层	数据翻译、格式化、语法选择	翻译（放哪里）	HTTP/HTML · FTP · Telnet · ASN.1（抽象语法记法）
5	会话层	两个会话层建立会话（session）：建立、管理、拆除、使用连接	电话沟通	ADSP·ASP·H.245·ISO-SP·iSNS·NetBIOS·PAP·RPC· RTCP·SMPP·SCP·SSH·ZIP·SDP（具有会话层功能）
4	传输层	发送端和接收端之间的传输；	具体路线	TCP · UDP · TLS · DCCP · SCTP ·RSVP · PPTP
3	网络层	多个网络之间相互传输，单位：分组； 定义通信规则：寻址、路由；连接建立、保持、终止；	规划	IP (IPv4 · IPv6) · ICMP · ICMPv6 · IGMP ·IS-IS · IPsec · BGP · RIP · OSPF ·ARP · RARP
2	数据链路层	2个设备之间传输数据包，单位：帧； 寻址方式、同步方式、差错控制、流量控制。	贴运单	Wi-Fi(IEEE 802.11) · WiMAX(IEEE 802.16) ·ATM · DTM · 令牌环 · 以太网路 ·FDDI · 帧中继 · GPRS · EVDO · HSPA · HDLC · PPP · L2TP · ISDN ·STP
1	物理层	2个设备之间传输比特流； 承接所有上层数据	修路	以太网路卡 · 调制解调器 · 电力线通信(PLC) · SONET/SDH（光同步数字传输网） ·G.709（光传输网络） · 光导纤维 · 同轴电缆 · 双绞线

共7层。从低层到高层依次为：

②数据链路层

常用协议：SLIP，PPP，X.25，帧中继。

常用差错检测：奇偶校验码、循环冗余码。

2）TCP/IP参考模型

TCP提供运输层服务，IP提供网络层服务。

层级	TCP/IP层	对应OSI层	作用	协议	设备
4	应用层	应用、表示、会话层		SNMP(简单网络net管理协议) SMTP（简单邮件Mail传送协议） FTP（文件传送协议） Telent（远程登录协议） DNS（域名DomainName解析，域名<->ip） HTTP（超文本传送协议） NAT（网络net地址address转换，私有IP转换为公有IP） IMAP（邮件internet mail访问access协议）
3	传输层	传输层+会话层部分功能	保障端到端可以会话	TCP、UDP（无连接） SPX：顺序包交换协议，是Novell NetWare网络的传输层协议
2	(互联)网络层	网络层	数据封装、传输； 分组路由和避免阻塞	ICMP（互联网控制control报文协议，主要用于ip主机和路由器之间传递控制消息：差错检测、网络探测与诊断，如ping命令）； IGMP（互联网组group管理协议，主机和路由器进行多播（组播）通信，如直播）； IPV4、IPV6（源和目的之间连接并传送数据包） X.25（架构广域网） ARP、RARP	路由器
1	物理和数据链路层（网络接口层）	物理层、数据链路层	基于物理介质，实现上层数据的成帧传输	ARP（地址解析Resolution协议，ip->mac）; RARP（反向Reverse地址解析协议，mac->ip）

9）NNTP（Network News Transfer Protocol，网络新闻传输协议）

用于在互联网上传输、分发、查询和获取网络新闻文章（通常指 Usenet 新闻组中的内容）的应用层协议

10）voip（Voice over Internet Protocol）

模拟信号（Voice）数字化，以数据封包（Data Packet）的形式在IP网络(IP Network）上做实时传递。

常用协议：sip会话发起协议，MGCP媒体网关控制协议，MEGACO（媒体网关之间的协议），h.323(IP电话）

13）syslog协议

1>概念

以UDP或者TCP协议来发送，发送端发送一个小的文字消息（小于1024位组、明文）到syslog接收端。
如果需要加密可以通过SSL/TLS方式提供一层加密。

协议格式：

1. facility模块（日志来源或设备）：

权重	来源	说明
0	kernel messages
1	user-level messages
2	mail system
3	system daemons
4	security/authorization messages
5	messages generated internally by syslogd
6	line printer subsystem
7	network news subsystem
8	UUCP subsystem
9	clock daemon
10	security/authorization messages
11	FTP daemon
12	NTP subsystem
13	log audit
14	log alert
15	clock daemon
16-23	local0 - local7

2. priority优先级（日志级别）
   facility + serverity共同计算出一个PRI头部。
   Priority（优先级） = facility * 8 + severity值，severity见下表。

Severity日志级别	权重	说明
Emergency	0	会导致系统不可用的
Alert	1	必须马上处理的
Critical	2	比较严重的错误
Error	3
Warning	4	可能影响系统功能，需要提醒用户的重要事件
Notice	5	不影响正常的功能，需要提醒用户的重要事件
Informational	6
Debug	7
*		表示所有的日志级别
none		跟*相反，表示什么也没有

3. header包含了时间和主机名
   TIMESTAMP是本机时间，采用的格式是“Mmm dd hh:mm:ss”；
   主机名无法识别显示的是IP地址，如果有多个ip会使用传送信息的ip。
4. MSG（日志消息体）
   在HEADER和MSG之间有一个空格。
   分为两部分：TAG + CONTENT。TAG域的值是产生信息的程序或者进程的名称，32位字母数字字符串。

2>场景

系统日志外发。

3>限制

4>java实现

7，Socket（套接字、长连接）

socket起源于Unix，而Unix/Linux基本哲学之一就是“一切皆文件”，都可以用“打开open –> 读写write/read –> 关闭close”模式来操作。我的理解就是Socket就是该模式的一个实现，socket即是一种特殊的文件，一些socket函数就是对其进行的操作（读/写IO、打开、关闭）

通过netstat -anpl | grep 18083可以监测到对应进程的socket状态。

1）流式套接字（对应TCP）

2）用户数据报套接字（对应UDP）

3）常用方法

①ServerSocket(int port)

是服务端绑定port端口，调accept()监听等待客户端连接，它返回一个连接队列中的一个socket。

②Socket(InetAddress address , int port)

创建客户端连接主机的socket流，其中InetAddress是用来记录主机的类，port指定端口。
socket和servletSocket的交互如下图所示：

4）连接状态

1、客户端独有的：（1）SYN_SENT （2）FIN_WAIT1 （3）FIN_WAIT2 （4）CLOSING （5）TIME_WAIT 。

2、服务器独有的：（1）LISTEN （2）SYN_RCVD （3）CLOSE_WAIT （4）LAST_ACK 。

3、共有的：（1）CLOSED （2）ESTABLISHED 。

1>LISTEN

侦听来自远方TCP端口的连接请求；

2>SYN-SENT

在发送连接请求后等待匹配的连接请求；

3>SYN-RECEIVED

在收到和发送一个连接请求后等待对连接请求的确认；

4>ESTABLISHED

代表一个打开的连接，数据可以传送给用户；

5>FIN-WAIT-1

等待远程TCP的连接中断请求，或先前的连接中断请求的确认；

6>FIN-WAIT-2

从远程TCP等待连接中断请求；

7>CLOSE-WAIT

对端关闭，我方需要主动处理这种情况。
问题现象：大量的CLOSE-WAIT（上千）可能导致程序访问时无法响应。
解决方式：一般是由于程序编写不合理造成的，捕捉监控对端关闭情况。

8>CLOSING

等待远程TCP对连接中断的确认；

9>LAST-ACK

等待原来发向远程TCP的连接中断请求的确认；

10>TIME-WAIT

主动关闭连接的一方，状态变为TIME-WAIT。此时会等待足够的时间（默认为2MS），以确保远程TCP接收到连接中断请求的确认，然后彻底关闭。
解决方式：一般通过优化内核参数能够解决。

通过ss -s 可以看到timewait已经有2w个了。

ss -s
Total: 174 (kernel 199)
TCP:   20047 (estab 32, closed 20000, orphaned 4, synrecv 0, timewait 20000/0), ports 10785

sysctl命令可以设置这些参数，如果想要重启生效的话，加入/etc/sysctl.conf文件中。

# 修改阈值
net.ipv4.tcp_max_tw_buckets = 50000 
# 表示开启TCP连接中TIME-WAIT sockets的快速回收
net.ipv4.tcp_tw_reuse = 1
#启用timewait 快速回收。这个一定要开启，默认是关闭的。
net.ipv4.tcp_tw_recycle= 1   
# 修改系統默认的TIMEOUT时间,默认是60s
net.ipv4.tcp_fin_timeout = 10

11>CLOSED

没有任何连接状态；

8，UDP丢包

1）原因

①接收端处理时间过长

调用recv方法接收端收到数据后，处理数据花了一些时间，处理完后再次调用recv方法，在这二次调用间隔里,发过来的包可能丢失。
对于这种情况可以修改接收端，将包接收后存入一个缓冲区，然后迅速返回继续recv。
或者一个线程用于接收数据，一个线程用于处理数据。

②发送的包巨大

虽然send方法会帮你做大包切割成小包发送的事情，但包太大也不行。例如超过50K的一个udp包，不切割直接通过send方法发送也会导致这个包丢失。这种情况需要切割成小包再逐个send。

③接受者接收缓存区不足

包超过mtu size数倍，几个大的udp包可能会超过接收者的缓冲，导致丢包。这种情况可以设置socket接收缓冲。以前遇到过这种问题，我把接收缓冲设置成64K就解决了。

④发送的包频率太快

虽然每个包的大小都小于mtu size 但是频率太快，例如40多个mut size的包连续发送中间不sleep，也有可能导致丢包，原因就是UDP的SendTo不会造成线程阻塞。这种情况也有时可以通过设置socket接收缓冲解决，但有时解决不了。所以在发送频率过快的时候还是考虑sleep一下吧。

⑤局域网内不丢包，公网上丢包

这个问题我也是通过切割小包并sleep发送解决的。如果流量太大，这个办法也不灵了。总之udp丢包总是会有的，如果出现了用我的方法解决不了，还有这个几个方法： 要么减小流量，要么换tcp协议传输，要么做丢包重传的工作。

9，在浏览器中输入网址后都发生了什么

1）浏览器发起DNS查询请求

浏览器会根据本地客户端DNS服务器配置(下图为DNS服务器配置)，向DNS服务器获取域名对应的IP地址。

2）域名服务器向客户端返回查询结果域名，从而完成域名到IP地址的转换。

3）客户端向web服务器发送HTTP请求

在得到了域名对应的IP地址后，客户端便可以向真正的web服务器发生HTTP请求了。

4）发送响应数据给客户端

Web服务器通常通过监听80端口，来获取客户端的HTTP请求。与客户端建立好TCP连接后，web服务器开始接受客户端发来的数据，并通过HTTP解码，从接受到的网络数据中解析出请求的url信息以前其他诸如Accept-Encoding、Accept-Language等信息。