url:统一资源定位符，在网络中唯一定义一份资源。
完整url组成：协议方案名称://用户名：密码@服务器地址:端口号/请求资源路径?查询字符串#片段标识符
url编码：在浏览器进行地址解析时，将用户提交给服务器的查询字符串中的特殊符号每一个字节按照十六进制进行转义，并且为了表示这个字符是经过url编码后的字符需要在转换后的字符前加上一个%。
编码规则：将需要转码的字符转为16进制，然后从右到左，取4位(不足4位直接处理)，每2位做一位，前面加上%，编码成%XY格式
url解码：在对端需要对经过url编码的数据进行url解码操作
http协议格式：首行：包含请求首行和响应首行
请求首行：请求方法(get无正文，post有正文）、url 、版本信息（0.9和1.0短连接；1.1和2属于长连接）
响应首行：协议版本 相应状态码(200、302、404、504) 状态码信息
header：以一个个Keyvalue组成的键值对构成，键值对之间以rn间隔
空行:用于间隔header和body
body:协议主体
http协议特点：传输灵活、无连接
传输层:负责端与端之间的数据传输端口：一个端口只能被一个进程占用，一个进程可以占用多个端口；一个端口就是一个数据通道，端口是一个无符号16位整数(0~65535)
五元组：网络中标识一条信息的具体流向，源端口、目的端口、源IP地址、目的IP地址、协议
udp协议(用户数据报协议)特点：无连接、不可靠、面向数据报
无连接、不可靠：通信时，通信双方不需要建立连接，只需要知道对端地址信息，就可以发送信息
面向数据报：数据只能整条向应用层交付
协议字段：16位源端口 16位目的端口 16位udp数据报数据的最大长度，包含udp首部和数据） 16位校验和
udp数据报长度决定了一个udp协议格式的数据最大长度不能超过64k-8，否则发送失败；当数据长度过大时需要用户在应用层进行数据分包
udp无法保证数据的有序到达，为了保证数据的有序到达，需要用户在应用层对数据进行包序管理
tcp协议（传输控制协议）特点：面向连接、传输可靠、面向字节流
16位源端口号：16位的源端口中包含初始化通信的端口。源端口和源IP地址的作用是标识报文的返回地址。
16位目的端口号：16位的目的端口域定义传输的目的。这个端口指明报文接收计算机上的应用程序地址接口。
32位序号：32位的序列号由接收端计算机使用，重新分段的报文成最初形式。当SYN出现，序列码实际上是初始序列码（Initial Sequence Number，ISN），而第一个数据字节是ISN+1。这个序列号（序列码）可用来补偿传输中的不一致。
32位确认序号：32位的序列号由接收端计算机使用，重组分段的报文成最初形式。如果设置了ACK控制位，这个值表示一个准备接收的包的序列码。
4位首部长度：4位包括TCP头大小，指示何处数据开始。
保留（6位）：6位值域，这些位必须是0。为了将来定义新的用途而保留。
标志：6位标志域。表示为：紧急标志、有意义的应答标志、推、重置连接标志、同步序列号标志、完成发送数据标志。按照顺序排列是：URG、ACK、PSH、RST、SYN、FIN。
16位窗口大小：用来表示想收到的每个TCP数据段的大小。TCP的流量控制由连接的每一端通过声明的窗口大小来提供。窗口大小为字节数，起始于确认序号字段指明的值，这个值是接收端正期望接收的字节。窗口大小是一个16字节字段，因而窗口大小最大为65535字节。
16位校验和：16位TCP头。源机器基于数据内容计算一个数值，收信息机要与源机器数值 结果完全一样，从而证明数据的有效性。检验和覆盖了整个的TCP报文段：这是一个强制性的字段，一定是由发送端计算和存储，并由接收端进行验证的。
16位紧急指针：指向后面是优先数据的字节，在URG标志设置了时才有效。如果URG标志没有被设置，紧急域作为填充。加快处理标示为紧急的数据段。
选项：长度不定，但长度必须为1个字节。如果没有选项就表示这个1字节的域等于0。
数据：该TCP协议包负载的数据。
相关面试题tcp三次握手：所谓的tcp三次握手是指在使用tcp建立通信时，通信双方总共需要发送三个确认数据包来确认连接的建立
第一次握手：客户端向服务端发出connect请求，给服务端发送一个SYN包（SYN=1）,然后等待服务端的回复，此时客户端进入SYN_SENT状态
第二次握手：服务端在收到客户端的SYN包后进行确认(ack=J+1），同时给客户端也发送一个SYN+ACK包(SYN=1,ACK=1)，服务端进入SYN_RCVD状态。
第三次握手：客户端在收到服务端的SYN+ACK包之后，向服务端发送一个ACK确认包(ack=K+1)，此包发送完成之后双方进入ESTABLISHED状态，三次握手完成。
SYN攻击：
在三次握手过程中，Server发送SYN-ACK之后，收到Client的ACK之前的TCP连接称为半连接，此时Server处于SYN_RCVD状态，当收到ACK后，Server转入ESTABLISHED状态。SYN攻击就是Client在短时间内伪造大量不存在的IP地址，并向Server不断地发送SYN包，Server回复确认包，并等待Client的确认，由于源地址是不存在的，因此，Server需要不断重发直至超时，这些伪造的SYN包将产时间占用未连接队列，导致正常的SYN请求因为队列满而被丢弃，从而引起网络堵塞甚至系统瘫痪。
tcp四次挥手：所谓四次挥手就是指当断开一个tcp连接时需要通信双发送四个确认包来确认连接断开。
第一次挥手：客户端在数据发送完毕之后，给服务端发送一个FIN包请求断开连接，此客户端进入FIN_WAIT状态
第二次挥手：服务端在收到客户端发来的FIN包之后，给客户端发送一个ACK确认包，此时服务端进入CLOSE_WAIT状态，客户端进入FIN_WAIT2状态
第三次挥手：服务端在数据接收完毕之后，也向客户端发送一个FIN包请求断开连接，此时服务端进入LAST_ACK状态。
第四次挥手：客户端收到服务端的FIN包之后进入TIME_WAIT状态，发送一个ACK包(ack=K+!)给服务端，服务端进入CLOSED状态
为什么tcp建立连接需要三次握手？
双方都进行确认是否具有数据收发能力，两次不安全，四次没必要
三次握手是为了防止，客户端的请求报文在网络滞留，客户端超时重传了请求报文，服务端建立连接，传输数据，释放连接之后，服务器又收到了客户端滞留的请求报文，建立连接一直等待客户端发送数据。
服务器对客户端的请求进行回应(第二次握手)后，就会理所当然的认为连接已建立，而如果客户端并没有收到服务器的回应呢？此时，客户端仍认为连接未建立，服务器会对已建立的连接保存必要的资源，如果大量的这种情况，服务器会崩溃。
为什么tcp断开连接需要四次挥手？
接收端被动关闭方接收到请求会后，进行ack确认，但是操作系统需要 用户处理完所有数据之后调用close才会发送FIN包
三次握手失败后，服务端是如何处理的？
三次握手的失败通常发生在第三次，务端会向客户端发送一个RST报文，销毁当前socket,重置连接
为什么TIME_WAIT状态需要经过2MSL(最大报文段生存时间)才能返回到CLOSE状态？
①保证TCP协议的全双工连接能够可靠关闭
②保证这次连接的重复数据段从网络中消失
假如没有TIME_WAIT，客户端直接关闭，但是又重启了相同地址的客户端，
有可能因为四次挥手最后一次的ACK丢失，导致服务端重传FIN包，对后序连接造成影响，
新客户端发送SYN到服务端，服务端认为状态有误，回复重置链接报文——RST报文
因此主动关闭方发送最后一个ACK后不能直接关闭，需要等待一段时间后(2个MSN时间)
MSN时间：报文最大生存周期
等待两个MSN时间是为了能够处理对端重传的FIN包进行ACK回复
并且等待两个MSL时间是为了让所有网络中延迟的报文都消失在网络中，不会对后序连接造成影响
服务端出现大量TIME_WAIT的原因及解决办法？
原因：程序主动退出会导致大量TIME_WAIT出现
解决方法：
1、设置套接字选项，使地址重复使用可以解决
2、减小TIME_WAIT等待时间
服务端出现大量CLOSE_WAIT的原因及解决办法？
原因：服务端没有正确关闭套接字，导致四次挥手失败
解决方法：加上正确的close方法即可
滑动窗口机制以及滑动窗口的流量控制
滑动窗口机制就是一次性发送固定量的数据然后等待回复。
滑动窗口的流量控制：通信双方在通信之间根据协议字段中的窗口大小协商接下来能够发送的数据的最大长度，窗口的大小不大于当前缓冲区的空闲空间的大小，避免因为一次性发送的数据过多导致缓冲区放慢，从而导致数据丢失重传
拥塞窗口机制
在传输数据时，初始窗口可能很大，此时若发送大量数据由于网络情况就会导致数据大量丢失，产生大量重传，导致数据传输效率降低；因此就需要一个拥塞窗口来控制发送端一次性发送数据的多少。这个拥塞窗口的大小会随着每次的ack响应而快速增长，一旦出现重传，则立即重新初始化。
超时重传机制
当发送端发送一条数据之后在固定的时间内没有收到确认回复，等待一定的时间之后，超时之后则认为数据丢失，就会重新发送该条数据。超时重传机制是为了保证数据的到达
快速重传机制
接收端在接收数据时，若没接收第一条数据，但是接收到了后续数据则认为第一条数据可能丢失，此时接收端会立即向发送端发送三条重传请求，发送端收到接收端的三条重传请求之后立即重传第一条数据。
延迟应答机制
在传数据传输时，每当发送端给接收端发送一条数据时就需要等待接收端回复一个确认应答的信息，这样会降低传输效率；延迟应答就是当接收端接收到数据之后等待一段时间之后再进行确认应答的回复 （一次性回复几条数据的确认应答），保证吞吐量，防止数据传输效率降低
捎带应答机制
，捎带应答就是接收端在给发送端发送数据的时候，捎带着向发送端发去确认应答，应答的内容是接收端已经收到发送端发送的数据，捎带应答可以保证尽可能避免大量纯报头(垃圾数据)的确认回复。
Tcp的粘包问题
产生原因：由于对要发送的数据没有明确边界造成的，可能发生在接收端也可能发生在发送端
解决方法：需要用户在应用层对数据进行边界划分
①加特殊字符进行间隔，但是有缺陷，容易与要发送的数据产生冲突
②数据定长（缺陷：数据短了浪费，长了需要分割）
③按照udp的做法，在不定长数据的应用协议头中定义数据报的长度