802.3、Rj45
SDLC、HDLC、PPP、STP
IP、IPX、ICMP、IGMP、ARP、RARP、OSPF
1）复用：多个应用层进程可以同时使用下面运输层的进程
2）分用：运输层把收到的信息分别交付给上面应用层中相应的进程。
ASP、ADSP
为什么需要三次握手？最主要的目的是双方确认自己与对方的发送与接受都是正常的。
1.第一次握手：客户端将SYN=1，随意产生一个序列号seq=x，将该数据包发送给服务端，客户端等待服务端确认
2.第二次握手：服务端收到标志位SYN=1知道客户端请求建立连接，将SYN和ACK置为1，随机生成一个值seq=y，并发送ack=x+1
3.第三次握手：客户端收到后确认检查，将ACK=1，ack=y+1，seq=x+1，并将数据包发送给服务端，服务端进行检查如果正确则连接建立成功，之后可以开始传输数据。
不行。主要是防止已经失效的链接请求报文又传送到服务器，产生错误，客户端发送的第一个链接请求可能没有丢失，只是因为在网络中滞留的时间过长。
1）由于TCP客户端没有收到确认报文，以为服务器没有收到，此时重新给服务器发送报文，服务器与客户端两次握手建立连接，传输数据然后关闭链接
2）此时滞留的连接请求到达服务器端，本身应该失效，但由于两次握手机制客户端与服务端再次建立连接，导致不必要的错误与资源的浪费
3）如果是三次握手，失效的报文到达服务端，服务端会向客户端发送确认，但客户端不会再次确认，由于服务端没有收到确认，并不会建立连接
利用TCP协议缺陷，发送大量的伪造TCP连接请求，常用假冒的IP和IP段发来海量的第一个握手包（SYN包），被攻击的服务端发送SYN/ACK包，等待客户端发送第三个握手包，但由于对方是假冒的IP，永远不会接受到第三个握手包，使得服务器的正常业务受到影响。
解决方法：SYNcookies技术
SYNcookies技术
当服务端收到SYN请求连接时，不直接为TCP分配资源，而是打开一个半开的套接字，使用SYN报文的源ID、目的ID、端口号和加密函数生成一个cookie，将cookie作为序列号发送给客户端。如果是正常链接，客户端会发送cookie+1的报文段，服务器会进行计算检查，如果正确则证明是正常的连接请求，此时才分配TCP资源
如果第三次ACK在网络中丢失，服务器端会保持半连接状态，根据超时重传机制服务端会等待3、6、12s重新发送SYN/ACK包，如果指定次数之后还未收到应答，服务端就关闭链接。但客户端会认为此时连接已建立，如果发送数据，服务端会返回RESET包，客户端就知道第三次握手失败了。
A为主动断开方，B为被动断开方
a向b发送FIN用来关闭之间的数据连接，b收到之后返回ACK报文，确认序号为收到的信号+1。b向a发送FIN表示关闭链接，a向b发送ACK报文表示确认，并将确认序号设置为收到序号+1.
为什么连接是三次握手？断开是四次挥手
1）在建立连接时，服务端处于listen状态下，把SYN与ACK放在一个报文段里发送给客户端。
2）关闭链接时，服务端接收到对方发送的FIN报文，仅表明对方不发送数据，服务端仍然可以发送数据，等数据发送完之后，再发送FIN报文告诉对方同意关闭，因此服务器的FIN与ACK是分开发送的，多了一次。
为什么TCP挥手每两次之间有一个wait等待时间？
主动关闭的一方再发送完数据之后进入wait状态，等待接收数据，如果此时被动关闭一方由于宕机等原因，使得主动关闭方不能收到被动关闭一方的FIN，就需要一个定时器，如果超时直接释放这个链接。
为什么客户端最后还要等2MSL?为什么还要TIME-WAIT等待时间
1）MSL是最大报文生存时间，一个MSL是30s，两个是60s
2）为了保证客户端发送的最后一个ACK报文发送到服务端，因为服务端在发送完ACK+FIN报文请求断开连接之后，客户端发送的ACK报文丢失，因此服务端会再次向客户端发送一次，而客户端就会在这个2MSL中收到这个重传报文，给出回应。
3）防止已经失效的连接请求报文段重新出现在连接中，客户端发送完ACK报文之后，可以使在该链接内产生的所有报文段都从网络中消失，保证新的连接不会出现旧连接的请求报文段
TIME-WAIT状态过多会产生什么后果 ？
短时间过多的短链接，会消耗服务端的资源/消耗客户端的端口，使得部分客户端连接不上，客户端无法发起新的链接。
在高并发短连接的TCP服务器上，可能会出现大量socket处在TIME_WAIT状态，如果并发量持续很高，部分客户端就会显示连接不上。高并发会让服务器短时间内占用大量端口，但是端口范围是0～65536，是有限的。短连接表示业务处理和传输数据的时间远小于TIMEWAIT超时的时间都连接。
解决办法：负载均衡；强制关闭，发送RST越过TIMEWAIT状态，直接CLOSE；设置SO_REUSEADDR套接字选项避免TIME_WAIT状态。
HTTP：超文本传输协议。设计HTTP最初的目的是为了提供一种发布和接受HTML页面的方法，使浏览器更加高效。HTTP协议以明文的方式发送信息，如果黑客截取了Web浏览器和服务器之间的传输报文，就可以直接获得其中的信息。
HTTPS：以安全为目标的HTTP通道，安全基础是SSL协议。HTTPS的设计目标是数据完整性、数据保密性、身份校验安全性。
HTTP与HTTPS的区别
1）HTTP以明文的方式发送数据，HTTPS则是具有安全性的SSL加密传输协议。
2）HTTPS协议需要使用到CA认证证书
3）HTTP简单连接无状态。（无状态是指数据包的发送、接收、传输都是相互独立的，通信双方都不长久的维持对方的信息）
DNS：基于UDP的应用层协议，功能是根据用户输入输入的域名，解析出该域名对应的IP地址，从而给客户端访问。
递归方式：
1）客户机发出查询请求，在本地计算机缓存查找，若没有找到，就会将请求发送给本地dns服务器
2）本地dns服务器会在自己的区域里面查找，找到即根据此记录进行解析，若没有找到，就会在本地的缓存里面查找
3）本地服务器没有找到客户机查询的信息，就会将此请求发送到根域名dns服务器
4）根域名服务器查找对应的顶级域名服务器
5）顶级域名服务器查找对应的权限域名服务器
6）权限域名服务器查找到对应的IP地址，并将该地址返还给主机
递归与迭代相结合：
1）客户机发出查询请求，在本地计算机缓存查找，若没有找到，就会递归查询将请求发送给本地dns服务器
2）本地域名服务器迭代查询根域名服务器，根域名服务器返回对应的顶级域名服务器地址
3）本地域名服务器查询顶级域名服务器，顶级域名服务器返回对应的权限域名服务器
4）本地域名服务器查询权限域名服务器，权限域名服务器返回相应的IP地址
5）本地域名服务器将IP地址返回给本地主机进行解析
为了提高DNS查询效率，并减轻服务器的负荷和减少因特网上的DNS查询报文数量，在域名服务器中广泛使用了高速缓存，用来存放最近查询过的域名以及从何处获得域名映射信息的记录。
超文本传输协议，它是基于TCP协议的应用层传输协议，是一种无状态的传输协议。
无状态：是指客户机与服务器之间不需要建立持久的连接，当客户机向服务器发送请求，服务器返回响应，连接就关闭了，在服务端不保留连接的有关信息。
报文结构：
1）请求报文：
2）响应报文：
http协议本身是无状态的，为了使其能处理更加复杂的逻辑，http1.1引入cookie来保存状态信息。
cookie由服务端产生，在发送给客户端保存，当客户端再次访问时，服务端可以通过cookie识别客户端，以此可以做个性化推送等。
session是记录客户状态的另一种机制，不同的是cookie存储在客户端浏览器中，而session存储在服务器上。当客户机以某种状态访问服务器时，服务器把客户端的信息以某种形式记录在服务器上，这就是session。客户端浏览器再次访问时只需要从该Session中查找该客户的状态就可以了。
1、cookie数据存放在客户的浏览器上，session数据放在服务器上.
2.cookie不是很安全，别人可以分析存放在本地的COOKIE并进行COOKIE欺骗考虑到安全应当使用session。
3.设置cookie时间可以使cookie过期。但是使用session-destory（），我们将会销毁会话。
4.session会在一定时间内保存在服务器上。当访问增多，会比较占用你服务器的性能考虑到减轻服务器性能方面，应当使用cookie。
两者最大的区别在于生存周期，一个是IE启动到IE关闭.(浏览器页面一关 ,session就消失了)，一个是预先设置的生存周期，或永久的保存于本地的文件。(cookie)
常见错误码：
转发是服务器行为。服务器直接向目标地址访问url，并将获取到的内容发送给浏览器，用户浏览器地址的url保持不变，转发页面可以共享request里的数据
重定向是服务端给客户端发送状态码，如果服务器返回301、302，浏览器收到消息之后会跳转到新的网址寻求资源。用户栏的url会改变，且不能共享数据。
1.浏览器将支持的加密算法信息发送给服务器
2.服务器选择一套浏览器支持的加密算法，以证书的形式发送给浏览器
3.客户端解析证书验证证书的合法性，生成对称加密的密钥，即客户端密钥，用服务器的公钥对客户端密钥进行非对称加密
4.客户端发起HTTPS中的第二个HTTP请求，将加密之后的客户端对称密钥发送给服务器
5.服务器接收到客户端发送的密文，使用自己的私钥对其进行非对称解密，解密之后获得客户端的密钥，使用客户端密钥对数据进行加密，这样数据就变成了密文
6.服务端将加密后的密文发送给客户端
7.客户端收到服务器发送的密文，使用客户端密钥进行对称解密，得到服务器发送的数据。这样HTTPS中的第二个HTTP请求结束，整个HTTPS传输完成
1.进行DNS解析操作，根据DNS解析的结果查找服务器IP地址
2.通过IP与ARP，找到服务器，三次握手建立连接
3.浏览器生成HTTP报文，发送HTTP请求，等待服务器响应
4.服务器处理请求，并返回给浏览器
5.根据HTTP是否开启长连接，进行TCP挥手过程
6.浏览器根据收到的静态资源进行页面渲染
7.页面显示完成后，浏览器发送异步请求
8.浏览器关闭TCP连接
发送端为了将多个发往接收端的包，更高效的发送给接收端，于是采用优化算法（Nagle算法），将多次间隔较小、数据量较小的数据，合并成一个数据量大的数据块，然后进行封包，接收端必须使用拆包机制来分辨数据。
1.什么是TCP粘包问题
TCP粘包就是发送端发送的若干包数据到达接收端时粘成了一包，从接收缓冲区看，后一包的数据紧接着前一包的数据尾，出现原因可能是发送方，也可能是接收方。
2.造成TCP粘包的原因
1）发送方原因
TCP默认使用Nagle算法，减少网络中的报文数，Nagle算法主要做两件事：
1.只有上一个分组得到确认，才会发送下一个分组
2.收集多个小分组，在一个确认到来时一起发送
Nagle算法造成了发送方会出现粘包问题
2）接收方原因
TCP接收到数据包时，并不会马上交付应用层处理，或者说应用层并不会立即处理。TCP将接收到的数据包保存在接收缓存里，然后应用程序主动从缓存读取收到的分组。这样一来，如果TCP接收数据包到缓存中的速度大于应用程序从缓存中读取数据包的速度，多个包就会被缓存，应用程序就有可能读取到多个首尾相连的粘包。
3.什么时候需要处理粘包现象？
1.如果发送方发送的多组数据本来就是同一块数据的不同部分，此时不需要处理粘包现象
2.如果多个分组毫不相干，甚至是并列关系，此时必须处理粘包现象。
4.如何处理粘包现象？
1）发送方
对于发送方造成的粘包问题，可以关闭Nagle算法解决。
2）接收方
接收方没法处理粘包现象，只能交给应用层处理。
3)应用层处理
解决方式：循环处理。应用程序从缓存中读取数据时，读完一条数据，循环读取下一条数据，知道所有数据都被处理完成。
判断数据的长度？
1.格式化数据：每条数据有固定的格式：开始符与结束符，但要保证数据内部不能包含开始符与结束符
2.发送长度：发送数据时，将数据的长度一并发送，例如规定数据的前四位是数据长度
5.UDP会不会产生粘包？
TCP为了保证可靠传输并减少额外的开销，采用基于流的传输，基于流的传输并不认为消息是一条一条的，是无保护消息边界的（保护消息边界：传输协议将数据当做一条独立的消息在网上传输，接收端一次性只能接受一条独立的信息）
UDP是面向消息传输的，有保护消息边界，接收方一次只接受一条独立信息，不存在粘包问题。
举个例子：有三个数据包，大小分别为2k、4k、6k，如果采用UDP发送的话，不管接受方的接收缓存有多大，我们必须要进行至少三次以上的发送才能把数据包发送完，但是使用TCP协议发送的话，我们只需要接受方的接收缓存有12k的大小，就可以一次把这3个数据包全部发送完毕。
联系客服
