2018秋招面试问题（九、关于网络通信）
注：面试过程中整理的学习资料，如有侵权联系我即刻删除。
目录
OSI模型有几层
简单介绍下socket的流程？connect完之后客户端和服务端都处于什么状态？对于多个客户端同时访问怎么办？怎么并发？怎么创建线程？如果是单线程、不并发会如何？（socket模型）
Socket阻塞和非阻塞
非阻塞的实现原理，socket如何实现非阻塞
介绍下tcp三次握手的过程？为什么两次不行，为什么不是四次？调用的是哪些系统API（windows下）？为什么握手是三次，而挥手是四次？
说一下四次挥手的FIN_WAIT_1和FIN_WAIT_2
说一下啊cose_wait发生在什么时候？last_ack呢？
time_wait状态是如何产生的？
Tcp协议的可靠性体现在哪些方面？
如何让UDP协议变得可靠？
画出tcp包的头
tcp的滑动窗口机制
如果接收端处理缓慢，导致滑动窗口变为0了，怎么办？
tcp的拥塞控制机制
tcp协议的缺陷？如何应对？
Tcp协议和Udp协议有什么区别？各自什么场合使用
为什么 TCP 叫数据流模式？ UDP 叫数据报模式？
tcp和udp的编程区别
udp的单播、广播和多播
tcp如果发一万个包，对方只能接收一百个怎么办？
DNS域名解析协议
DNS使用什么协议？
arp协议
ping发生在网络模型的哪一层？
简述一下ping的原理
列举几个应用层的协议，他们分别用了什么传输层协议
ip报文传输的过程
ip数据包在传输的过程当中哪些数据会发生改变？
tcp/ip协议与http协议的区别
http协议和https协议的区别
http访问一个网页的完整过程
http报文格式
http协议
Http的无状态、无连接代表什么意思
什么是session机制
什么是session机制
URL和URI
http状态码404
get 和post区别
https的知识
如何在一个不安全的环境中实现安全的数据通信？
路由器和交换机比较
OSI模型有几层
OSI是指使各种计算机在世界范围内互连为网络的标准框架。
包含有七层：应用层、表示层、会话层、传输层、网络层、数据链路层、物理层。
简单介绍下socket的流程？connect完之后客户端和服务端都处于什么状态？对于多个客户端同时访问怎么办？怎么并发？怎么创建线程？如果是单线程、不并发会如何？（socket模型）
- 服务端：建立socket，声明自身的端口号和地址并绑定到socket，使用listen打开监听，然后不断用accept去查看是否有连接，如果有，捕获socket，三次握手完毕之后，通过recv获取消息的内容，通信完成后调用closeSocket关闭这个对应accept到的socket，如果不再需要等待任何客户端连接，那么用closeSocket关闭掉自身的socket。
客户端：建立socket，通过端口号和地址确定目标服务器，使用Connect连接到服务器，send发送消息，等待处理，通信完成后调用closeSocket关闭socket。
- 通过多线程的方式实现多客户端连接与服务器连接。
服务端每次接收到一个新的socket连接，都新开一个线程来单独处理这个socket。
- 如果是单线程、不并发，那么之后客户端的连接请求会阻塞，直到第一个客户端完成操作。
（accept队列为空，叫阻塞；连接上之后客户端和服务器迟迟不发数据，这也叫阻塞；单线程多客户端也叫阻塞；）
<服务端有几种模式>：https://blog.csdn.net/s3FRH3JyN6yymHmT11/article/details/78871563
Socket阻塞和非阻塞
- 阻塞模式下：
connect发SYN请求服务器，当客户端收到服务器发回的ACK确认号之前，connect一直阻塞，收到确认号之后才返回。
accept在连接队列中没有建立好连接时将阻塞，直到有可用的连接才返回。
当socket的接收缓冲区中没有数据时，read调用会一直阻塞住，直到有数据到来才返回。
如果发送缓冲区没有空间或者空间不足的话，write操作会直接阻塞住，如果有足够空间，则拷贝所有数据到发送缓冲区，然后返回。
- 非阻塞模式下：
connect函数并不等待连接建立好才返回，而是立即返回，返回一个错误码。
accept也是，有没有连接都会立即返回，返回一个错误码。
read和write也会立刻返回。
非阻塞的实现原理，socket如何实现非阻塞
当使用socket函数创建套接字时，默认都是阻塞的，通过调用ioctlsocket()函数，将该套接字设置为非阻塞模式。使用非阻塞套接字在调用函数时，会经常返回WSAEWOULDBLOCK错误。
介绍下tcp三次握手的过程？为什么两次不行，为什么不是四次？调用的是哪些系统API（windows下）？为什么握手是三次，而挥手是四次？
SYN：同步序列编号，发起一个新连接
ACK：确认序号有序。
SYN就是询问： 你能听得到吗？ ACK就是回到： 我能听得到啊。
第一次握手：建立连接时,客户端发送syn包到服务器,并进入SYN_SENT状态,等待服务器确认；
第二次握手：服务器收到syn包,必须确认客户的SYN,同时自己也发送一个SYN包,即SYN+ACK包,此时服务器进入SYN_RECV状态；
第三次握手：客户端收到服务器的SYN＋ACK包,向服务器发送确认包ACK,此包发送完毕,客户端和服务器进ESTABLISHED状态,完成三次握手。
- “三次握手”的主要目的是为了防止在某个网络结点滞留的连接请求，已经失效了，又传送到了服务端，服务端收到这个连接请求之后以为客户端要发起一次新的连接，就会给客户端发送确认号，如果不是三次握手的话，新的连接就建立了。但是客户端不会理会服务端，造成服务端资源的浪费。
- 如果四次，那么就造成了浪费，因为在三次结束之后，就已经可以保证A可以给B发信息，A可以收到B的信息； B可以给A发信息，B可以收到A的信息。（有这样的疑问，既然第二次都没法确定A能否收到消息，那第三次怎么能确定B能收到消息呢？没法收到，不错，这根本没法确定，因为完全可靠的通信协议是根本不存在的，我们任何的通信协议都是在接受这样的现实情况之上进行的。而三次握手后，C和S至少可以确认之前的通信情况，但无法确认之后的情况。 在这个道理上说，无论是四次还是五次或是更多次都是徒劳的）
- connect、listen、accept。
connect用在客户端，listen和accept用在服务端。
- 四次挥手是为了确保数据可以完全传输。
挥手的时候由一端A发起断开连接FIN的请求（A进入fin_wait1状态），另一端B发回一个确认号ACK(B发了ack之后就进入close_wait状态，A收到ack之后进入fin_wait2状态)，此时B可能还有消息没发送完毕，继续发送...待B消息全部发送完毕，会发FIN给A(B进入last_ack状态)，A再发一个确认号ACK给B（A进入time_wait状态），等待2msl的时间，确定B收到消息，否则再给B发送一个ACK号再关闭。
所以挥手需要四次。
说一下四次挥手的FIN_WAIT_1和FIN_WAIT_2
FIN_WAIT_1实际上是socket在established状态时，它想主动关闭连接，向对方发送FIN报文，此时的socket就进入到FIN_WAIT_1状态。当对方回复ACK确认号后，socket就进入FIN_WAIT_2状态。在实际情况下，都要马上回复ACK报文，所以FIN_WAIT_1状态比较难看到。
说一下啊cose_wait发生在什么时候？last_ack呢？
处于close_wait的话说明套接字是被动关闭的，收到对方的FIN就会给对方发一个ACK确认号，然后就会进入到close_wait状态。等到自己东西发完了再给对方发一个FIN，再进入last_ack状态。
time_wait状态是如何产生的？
是主动关闭连接的那一方，在发送最后一个ack包之后会进入time_wait状态，会保持2MSL时间才会进入初始状态。MSL是数据包在网络中的最大生存时间。
time_wait状态产生的原因是：
- 为实现TCP这种全双工（full-duplex）连接的可靠释放。
（最后一个ack丢失的话对方会重发fin，这边再重发ack）
- 为使旧的数据包在网络因过期而消失。防止连续两次连接时，后一次收到了前一次连接中滞留的包。
但是有大量的time_wait状态，会很占用资源影响资源。
Tcp协议的可靠性体现在哪些方面？
有超时重传、校验码、序列号、流量控制。
- 为了防止信息包丢失，当tcp发出一个报文段后，会启动一个定时器，等待目的端收到这个报文段，如果没有及时收到一个确认，将重新发这个报文段。（超时重传）
- 为了防止数据在传输过程中被损坏，每个信息包都包含一个校验码，这个校验码就是用来保证这个信息包在传输过程中没有被修改的一个代码。当信息到达目的地时，接收端会比较这个校验码和信息包中收到的数据，如果校验码不对则会舍弃这个信息包。（校验码）
< 发送之前会根据数据计算一下校验码，收到的时候还会再根据数据计算校验码，如果数据发送改变则校验码对不上，就会丢弃这个包。>
- 为了防止信息包重复或者顺序错误，tcp每传送一个信息包都会发送一个序列号，接收端会检查这个序列号，并返回确认，把全部信息包按照序列号重新合并，如果接收端检查到一个已接收的序号，那么这个信息包就会被丢弃。（按序到达）
- Tcp还提供流量控制，tcp连接的每一方都有固定大小的缓冲空间。Tcp的接收端只接受另一端发送接收端所能接纳的数据，这个将防止较快主机致使较慢主机的缓冲区溢出。（滑动窗口来进行流量控制）
如何让UDP协议变得可靠？
UDP的报头一共只有8个字节，分别为：源端口号、目的端口号、数据报长度以及校验和，其中每个域各占用2个字节。
可以对原有UDP增加一些控制机制，如丢包重发、错序重排等。增加UDP的头信息：2个字节的数据包标识，2个字节的发送序号，2个字节的文件指针定位和2个字节的数据包中数据大小信息。
< 数据包标志指明该数据包为文件数据包、确认包或者其它控制包，发送序号用来指明数据包的顺序信息，指针定位字节数据用来指明该数据包中数据被填写到文件的哪个位置，最后的大小信息也是用来向文件中读写数据时使用。>
这里面有三个机制使得udp变得可靠，一是确认机制、二是错序重排机制、三是重发机制。
具体过程：
- 首先发送端发送一个文件信息报文，这个报文就是最简单的UDP报文，但是里面的信息很重要，记录着文件的大小，被分隔成的报文数，文件序号数。发完这个信息包，发送端阻塞，等待接收端的回复报文才能继续。
- 然后接收端收到报文给发送端发一个确认号，发送端收到这个确认号的话，就会把这个文件的整组数据报全部发送过去。（不像TCP每个报文都要确认才能收发下一个报文）
- 接收端在接收这组报文的时候将遵守错序重排机制，来对收到的这组报文进行按序号排序，期间可能序号不连续不过没关系，接受过程只要保证序号从小到大即可。发送端发送完所有数据包之后再发一个结束报文，接收端收到结束报文之后再按照一开始的文件信息包的信息和序列号做对比，把没有收到的序列号报文信息传回发送端，要求重发。
发送端重发，最后直到接收端全部接收完毕，就给发送端发回一个接收完毕的报文。这样这个文件传输就结束了，接收端就可以开始下一个文件传输。
画出tcp包的头
| 源端口（2字节） |
目的端口（2字节） |
| 序号（4字节） |
|
| 确认号（4字节） |
|
| Dataoffset4位 、保留字段、标志位各6位 |
窗口字段（2字节） |
| 校验和（2字节） |
紧急指针（2字节） |
一共20个字节。Udp的头只有第一行和最后一行。
序号是包的序号，用来解决网络包乱序的问题。
确认号是ack，指的是下一个期待的字节，用于确认收到，用来解决丢包问题。（收到接收方发送的ACK是5就表示他下一次希望收到的数据是5，发送方就知道我刚才发送的2个数据对方收了，这个时候开始发送第5个数据）
窗口就是指滑动窗口，用来解决流量控制的问题。
标志位，就是包的类型，URG、ACK、PSH、RST、SYN、FIN，用来把握tcp的状态。
tcp的滑动窗口机制
TCP是通过滑动窗口来进行流量控制。
在TCP头部里有一个字段叫 窗口大小。这个字段是接收端告诉发送端自己还有多少缓冲区可以接收数据，于是发送端就可以根据这个窗口大小来发送数据。这样就控制了发送端的数据发送，进行流量控制。
如果接收端处理缓慢，导致滑动窗口变为0了，怎么办？
这时发送端就不发数据了，但发送端会发ZWP（即Zero Window Probe技术）的包给接收方，让接收方回ack更新窗口大小，一般这个值会设置3次，每次大约30-60秒。如果3次过后还是0的话，有的TCP实现就会发RST把连接断了。
tcp的拥塞控制机制
拥塞是指：对资源的请求超过了可用资源的大小，若网络中许多资源同时供应不足，网络的性能就会明显变坏。
拥塞控制机制：就是采用一些方法，防止过多的数据注入到网络中，使网络能够承受现有的网络负荷。
拥塞控制方法：
慢开始、拥塞避免、快重传、快恢复。
慢开始：是指由小到大的增大发送窗口，将拥塞窗口cwnd一开始设为1，然后再逐渐增大cwnd，每经过一个往返时间RTT，就将cwnd加倍，还需要设置一个慢开始门限状态变量，防止cwnd增长过快而导致网络拥塞。
拥塞避免：让拥塞窗口cwnd更加缓慢地增大，即每经过一个往返时间RTT就把发送方的拥塞窗口cwnd加1，而不是加倍。这样拥塞窗口cwnd按线性规律缓慢增长，比慢开始算法的拥塞窗口增长速率缓慢得多。
快重传：
< 快重传要求接收方只要收到失序的报文段就立即发出重复确认。>
接收方收到了M1和M2后都分别发出了确认。现在假定接收方没有收到M3但接着收到了M4。显然，接收方不能确认M4，因为M4是收到的失序报文段。根据可靠传输原理，接收方可以什么都不做，也可以在适当时机发送一次对M2的确认。但按照快重传算法的规定，接收方应及时发送对M2的重复确认，这样做可以让发送方及早知道报文段M3没有到达接收方。发送方接着发送了M5和M6。接收方收到这两个报文后，也还要再次发出对M2的重复确认。这样，发送方共收到了接收方的四个对M2的确认，其中后三个都是重复确认。快重传算法还规定，发送方只要一连收到三个重复确认就应当立即重传对方尚未收到的报文段M3，而不必继续等待M3设置的重传计时器到期。
快恢复：
当发送方连续收到三个重复确认，把慢开始门限ssthresh减半，用来预防网络发生拥塞。慢开始门限ssthresh减半之后，执行拥塞避免算法。
tcp协议的缺陷？如何应对？
引起泛洪效应。SYN- Flood攻击是当前网络上最为常见的DDoS攻击，也是最为经典的拒绝服务攻击，它就是利用了TCP协议实现上的一个缺陷，通过向网络服务所在端口发送大量的伪造源地址的攻击报文，就可能造成目标服务器中的半开连接队列被占满，从而阻止其他合法用户进行访问。
原理：攻击者首先伪造地址，对服务器发起SYN请求，服务器回应(SYN+ACK)包，而真实的IP会认为，我没有发送请求，不作回应。服务器没有收到回应，这样的话，服务器不知道(SYN+ACK)是否发送成功，默认情况下会重试5次（tcp_syn_retries）。这样的话，对于服务器的内存，带宽都有很大的消耗。
应对方法：
- 拆除掉掉半开连接和不活动连接，释放系统资源。
- 延缓TCB资源分配（两种方法：a.收到SYN时不急着分配TCB，而是回应一个ACK报文，直到收到对方正确的ACK再分配TCB；b.收到对方的ACK报文之后，重新计算一下，看是否与记录的sequence number-1（上一个泛洪序列号）相同，从而决定是否分配TCB资源）。
防火墙验证。
Tcp协议和Udp协议有什么区别？各自什么场合使用
tcp面向连接，而udp是无连接的。
tcp提供可靠的服务，通过tcp连接传送的数据，尽可能无差错，不丢失，不重复，且按序到达。udp不保证可靠交付。
udp没有拥塞机制，因此网络出现拥塞不会使主机发送速率降低。这就对实时应用很有用，如ip电话、实时视频会议等。（丢包就丢包，发还是照常发）
每一条tcp连接都是一对一的，而udp支持一对一、一对多、多对一、多对多的交互通信。
tcp对系统资源的要求更多，udp对系统资源的要求较少。
像远程视频，qq大部分都是用的udp协议，而传收文件，一般都是用tcp协议。
为什么 TCP 叫数据流模式？ UDP 叫数据报模式？
数据流模式是指TCP发送端发送几次数据和接收端接收几次数据是没有必然联系的。<这是因为TCP是面向连接的，一个 socket 中收到的数据都是由同一台主机发出，且有序地到达，所以每次读取多少数据都可以。>
数据报模式是指发送端发送了几次数据，那么接收端就得接收几次数据，每次最多只能读取一次报文。
< 这是因为UDP是无连接的，只要知道接收端的 IP 和端口，任何主机都可以向接收端发送数据。 这时候，如果一次能读取超过一个报文的数据， 则会乱套。因为可能上一个报文是a主机的，而下一个报文是b主机的。 >
tcp和udp的编程区别
socket()的参数不同 ；UDP Server不需要调用listen和accept ；UDP收发数据用sendto/recvfrom函数 ；TCP：地址信息在connect/accept时确定 ； UDP：在sendto/recvfrom函数中每次均需指定地址信息 ；UDP：shutdown函数无效。
TCP通信中：socket(PF_INET, SOCK_STREAM, 0)，这表示建立一个socket用于流式网络通讯。
UDP中，socket(PF_INET, SOCK_DGRAM, 0)，任何一方建立一个socket以后就可以用sendto发送数据，也可以用recvfrom接收数据。
udp的单播、广播和多播
单播是两个主机之间的端对端通信，广播是一个主机对整个局域网上所有主机上的数据通信，而多播是一个主机对一组特定主机的数据通信。
- 广播地址255.255.255.255，广播只允许在局域网中，本地广播信息是不会被路由器转发，因为如果路由器转发了广播信息，那么势必会引起网络瘫痪。广播还是要指明接收者的端口号。
- 单播和多播都允许在广域网上进行传输，多播的应用主要有网上视频、网上会议等。
多播服务器的总带宽不受客户端带宽的限制。由于组播协议由接收者的需求来确定是否进行数据流的转发，所以服务器端的带宽是常量，与客户端的数量无关。多播的ip地址范围是224.0.0.0至239.255.255.255之间的IP地址。
Ps：访问一个web服务器，就是访问它的80端口。
tcp如果发一万个包，对方只能接收一百个怎么办？
在接收端和发送端的链路中间加一个中继器，由中继器将一万个包组成一百个包，再传给接收端。
或者接收端告诉发送端自己的窗口大小，进行流量控制，让发送端将一万个包拆分成一百个用一百次发过来。
DNS域名解析协议
一个域名只能对应一个ip，但是一个ip可以对应多个域名。
DNS就是把域名和ip地址映射起来的分布式数据库。
- 一般来说，浏览器会首先查看本地硬盘的 hosts 文件，看看其中有没有和这个域名对应的规则，如果有的话就直接使用 hosts 文件里面的 ip 地址。
- 如果在本地的 hosts 文件没有能够找到对应的 ip 地址，浏览器会发出一个 DNS请求到本地DNS服务器。
- 查询你输入的网址的DNS请求到达本地DNS服务器之后，本地DNS服务器会首先查询它的缓存记录，如果缓存中有此条记录，就可以直接返回结果，此过程是递归的方式进行查询。如果没有，本地DNS服务器还要向DNS根服务器进行查询。
- 根DNS服务器没有记录具体的域名和IP地址的对应关系，而是告诉本地DNS服务器，你可以到域服务器上去继续查询，并给出域服务器的地址。这种过程是迭代的过程。
- 域服务器也不直接返回ip地址与域名的对应关系，而是告诉本地DNS服务器，能解析这个域名的服务器的地址。
最后，本地DNS服务器向域名的解析服务器发出请求，这时就能收到一个域名和IP地址对应关系，本地DNS服务器不仅要把IP地址返回给用户电脑，还要把这个对应关系保存在缓存中，以备下次别的用户查询时，可以直接返回结果，加快网络访问。
DNS使用什么协议？
DNS是应用层的协议，使用了TCP和UDP协议。
arp协议
arp协议是网络层的协议，是映射ip地址和mac地址的一个表，可以根据ip地址找mac地址。
ping发生在网络模型的哪一层？
网络层，ping是为了检测网络是否通畅，基于icmp协议。
ping + 域名
简述一下ping的原理
ping就是给目标IP地址发送一个 ICMP 回显请求，并要求对方返回一个 ICMP 回显应答来确定两台网络机器是否连通，时延是多少。
在 ICMP 逐层封装的过程中，需要知道源IP、源MAC地址、目的IP、目的MAC地址，前三者是已知的，只需要获取目的MAC地址即可，通过arp协议来获得目的MAC地址：
< 若在同一网段，只需要发送ARP广播；
若不在同一网段，发送ARP广播给交换机，交换机若没有缓存目的IP对应的MAC地址，它会再转发该ARP广播包。>
列举几个应用层的协议，他们分别用了什么传输层协议
http ftp dns（域名解析协议，通过域名来找到对应的IP地址）
http用到了tcp协议，dns用到了tcp和udp协议。
ip报文传输的过程
主机将数据包发送到默认网关，再由路由器在路由表中发现目标网络，传到下一个更接近目标的路由器，再到下一个路由器，最终由目的mac地址传到目标主机。
ip报文传输过程包括：
1. Host sends packet to default gateway（主机将数据包发送到默认网关）
2. Packet placed in frame（数据包被封装入帧）
3. Router receives frame（路由器接到帧）
4. Router finds destination network in route table（路由器在路由表中发现目标网络）
5. Router chooses next hop toward destination（路由器选择一个更接近目标的下一跳）
6. MAC address of next hop determined（下一跳的MAC地址被确定）
7. Packet placed in frame（数据包被封装入帧）
8. Repeats steps 2 through 7 as necessary（如果需要的话，重复步骤2～7）
9. Router receives frame（路由器接到帧）
10. Router finds network directly connected（路由器发现直连网络）
11. MAC address of end host determined（最终主机的MAC地址被确定）
12. Packet placed in frame to final destination（帧中的数据包被发送到最终主机）
ip数据包在传输的过程当中哪些数据会发生改变？
源物理地址和目的物理地址会发生改变，源ip地址应该不会改变。比如经过好几个路由器。
tcp/ip协议与http协议的区别
tcp/ip协议是传输层的协议，主要解决的是数据如何在网络中传输，只关注传输。http是应用层协议，主要解决如何包装数据，定义传输数据内容的规范。
实际应用中，我们访问一个网页，首先就要跟服务器建立tcp/ip连接，建立tcp连接之后，才能用http协议来传送数据，给服务器发http请求。
“IP”代表网际协议，TCP和UDP使用该协议从一个网络传送数据包到另一个网络。把IP想像成一种高速公路，它允许其它协议在上面行驶并找到到其它电脑的出口。TCP和UDP是高速公路上的“卡车”，它们携带的货物就是像HTTP，文件传输协议FTP这样的协议等。
http协议和https协议的区别
http不安全 很容易被监测，https更安全，用了一套密钥交换机制，实现了加密通信，基于ssl协议。
http访问一个网页的完整过程
域名解析查找ip地址--> 发起TCP的3次握手 --> 建立TCP连接后发起http请求 --> 服务器响应http请求，浏览器得到html代码 --> 浏览器解析html代码，并请求html代码中的资源（如js、css、图片等） --> 浏览器显示出来当输入一个网址，
在应用层中，客户端浏览器先通过DNS域名解析协议将URL解析为ip地址，（通过这个地址来寻找客户端到服务端的路径）然后发起一个http会话，交给传输层处理。
在传输层中，浏览器会向服务器发起tcp连接，三次握手连接上之后发起http请求。将http会话请求分为tcp报文段，再添加上源端口和目的端口，交给网络层。
在网络层中，通过查找路由表来确定如何到达服务器。
在数据链路层，包通过链路层发送到路由器，通过arp协议查找给定ip地址的mac地址。
经过这些步骤，最后把http请求发送到服务器这里。
http报文格式
http报文是由状态行、响应头、响应正文组成的。
状态行中包括了请求方法、URL、版本。用来说明请求的目的。
响应头包含的是客户端的各种关于内容格式、语言类型等的请求。
响应正文就是就是报文的具体数据。
http协议
http协议：超文本传输协议，HTTP是一个基于TCP/IP通信协议来传递数据（HTML 文件, 图片文件, 查询结果等）。
HTTP协议工作于客户端-服务端（C/S）架构为上。浏览器作为HTTP客户端通过URL向HTTP服务端即WEB服务器发送所有请求。Web服务器根据接收到的请求后，向客户端发送响应信息。
主要特点：
1、简单快速：客户向服务器请求服务时，只需传送请求方法和路径。请求方法常用的有GET、HEAD、POST。每种方法规定了客户与服务器联系的类型不同。由于HTTP协议简单，使得HTTP服务器的程序规模小，因而通信速度很快。
2、灵活：HTTP允许传输任意类型的数据对象。正在传输的类型由Content-Type加以标记。
3、无连接：无连接的含义是限制每次连接只处理一个请求。服务器处理完客户的请求，并收到客户的应答后，即断开连接。采用这种方式可以节省传输时间。
4.无状态：HTTP协议是无状态协议。无状态是指协议对于事务处理没有记忆能力。缺少状态意味着如果后续处理需要前面的信息，则它必须重传，这样可能导致每次连接传送的数据量增大。另一方面，在服务器不需要先前信息时它的应答就较快。
Http的无状态、无连接代表什么意思
无状态代表http对事务没有记忆能力。
比如：A购买了一件商品放入购物车内，当再次购买商品时，服务器已经无法判断该购买行为属于用户A还是用户B的会话了，要想跟踪会话，必须引入一种机制。
无连接是指限制每次连接只能处理一个请求。
什么是cookie机制
Cookie是存储在用户本地终端上的数据。
由于http是无状态协议，服务器单从网络连接上无从得知客户身份，就给客户端颁发一个通行证吧，每人一个，无论访问什么都必须携带自己的通行证。这样服务器就能从通行证确认客户身份了，并把这个通行证所进行的所有操作都归为一个会话。Cookie对象使用key-value属性对的形式保存用户状态，一个Cookie对象保存一个属性对，一个request或者response同时使用多个Cookie。Cookie是不可跨域名的，比如Google和baidu各自只能操作自己的Cookie，而不能操作对方的Cookie。
像保存登陆信息自动登陆，是把登录信息如账号、密码等保存在Cookie中，并控制Cookie的有效期，下次访问时再验证Cookie中的登录信息即可。验证的时候一般是把密码加密后保存到Cookie中，下次访问时解密并与数据库比较，要查询数据库。
什么是session机制
Cookie和Session机制都是服务器用来记录客户端状态的一种机制。
Session方法上比Cookie简单一些，相应的也增加了服务器的存储压力。Cookie是保存在客户端中，而Session是保存在服务器上。Session相当于在服务器中存储了一份客户档案，客户端浏览器访问的时候只需要查询这个档案就行。为了更高的存取速度，服务器一般把Session存放在内存里，每个用户都会有一个独立的Session，用户第一次访问的时候会自动创建Session。如果Session内容过于复杂，当大量客户访问服务器时可能会导致内存溢出。Session随着用户的访问会越来越多，所以服务器会把长时间没有活跃的Session从内存中剔除。这个时间就是Session的超时时间。如果超过了超时时间没访问过服务器，Session就自动失效了。
Session是通过Cookie来识别是否是同一用户的，但是绝大多数的手机浏览器都是不支持cookie的，这样就得用URL重写来跟踪用户会话。
当程序需要为某个客户端的请求创建一个session时，服务器首先检查这个客户端的请求里是否已包含了一个session标识（称为session id），如果已包含则说明以前已经为此客户端创建过session，服务器就按照session id把这个session检索出来使用（检索不到，会新建一个），如果客户端请求不包含session id，则为此客户端创建一个session并且生成一个与此session相关联的session id，这个session id将被在本次响应中返回给客户端保存，保存这个session id的方式可以采用cookie，也可以用URL重写，就是把session id直接附加在URL路径的后面。
什么是session机制
Cookie和Session机制都是服务器用来记录客户端状态的一种机制。
Session方法上比Cookie简单一些，相应的也增加了服务器的存储压力。Cookie是保存在客户端中，而Session是保存在服务器上。Session相当于在服务器中存储了一份客户档案，客户端浏览器访问的时候只需要查询这个档案就行。为了更高的存取速度，服务器一般把Session存放在内存里，每个用户都会有一个独立的Session，用户第一次访问的时候会自动创建Session。如果Session内容过于复杂，当大量客户访问服务器时可能会导致内存溢出。Session随着用户的访问会越来越多，所以服务器会把长时间没有活跃的Session从内存中剔除。这个时间就是Session的超时时间。如果超过了超时时间没访问过服务器，Session就自动失效了。
Session是通过Cookie来识别是否是同一用户的，但是绝大多数的手机浏览器都是不支持cookie的，这样就得用URL重写来跟踪用户会话。
当程序需要为某个客户端的请求创建一个session时，服务器首先检查这个客户端的请求里是否已包含了一个session标识（称为session id），如果已包含则说明以前已经为此客户端创建过session，服务器就按照session id把这个session检索出来使用（检索不到，会新建一个），如果客户端请求不包含session id，则为此客户端创建一个session并且生成一个与此session相关联的session id，这个session id将被在本次响应中返回给客户端保存，保存这个session id的方式可以采用cookie，也可以用URL重写，就是把session id直接附加在URL路径的后面。
URL和URI
HTTP使用统一资源标识符（Uniform Resource Identifiers, URI）来传输数据和建立连接。URL是一种特殊类型的URI，包含了用于查找某个资源的足够的信息（不仅可以标识，而且可以定位资源）
URL,全称是UniformResourceLocator, 中文叫统一资源定位符,是互联网上用来标识某一处资源的地址，除了标识资源的位置，还提供一种定位该资源的主要访问机制。
http状态码404
状态代码由三位数字组成，第一个数字定义了响应的类别，共分五种类别:
1xx：指示信息--表示请求已接收，继续处理
2xx：成功--表示请求已被成功接收、理解、接受
3xx：重定向--要完成请求必须进行更进一步的操作
4xx：客户端错误--请求有语法错误或请求无法实现
5xx：服务器端错误--服务器未能实现合法的请求
常见状态码：
200 OK //客户端请求成功
400 Bad Request //客户端请求有语法错误，不能被服务器所理解
401 Unauthorized //请求未经授权，这个状态代码必须和WWW-Authenticate报头域一起使用
403 Forbidden //服务器收到请求，但是拒绝提供服务
404 Not Found //请求资源不存在，eg：输入了错误的URL
500 Internal Server Error //服务器发生不可预期的错误
503 Server Unavailable //服务器当前不能处理客户端的请求，一段时间后可能恢复正常
get 和post区别
向服务器提交文件、表单、数据、输入账号密码，基本上都是用post。
访问一个浏览网页，可以用get。
get通过url传递，post放在request body(请求体)中。
get请求在url中传递的参数是有长度限制的，而post没有。
get比post更不安全，因为参数直接暴露在url中，所以不能用来传递敏感信息。
get请求只能进行url编码，而post支持多种编码方式
get请求会浏览器主动cache，而post支持多种编码方式。
get请求参数会被完整保留在浏览历史记录里，而post中的参数不会被保留。
get和post本质上就是TCP链接，并无差别。但是由于HTTP的规定和浏览器/服务器的限制，导致他们在应用过程中体现出一些不同。
get产生一个TCP数据包；post产生两个TCP数据包。
对于get方式的请求，浏览器会把http header和data一并发送出去，服务器响应200（返回数据);
而对于POST，浏览器先发送header，服务器响应100 continue，浏览器再发送data，服务器响应200 ok（返回数据）。
http: 源地址发起请求得到目的地址，确定是哪两个进程间相互通信。
Tcp：不同进程间建立连接通信。
Ip：这两个进程所在的计算机相互连接通信。
这些协议对应的客户端和服务器都是同样的，一次通信全部协议都要用到。
https的知识
https的工作原理：
（1）客户使用https的URL访问Web服务器，要求与Web服务器建立SSL连接。
（2）Web服务器收到客户端请求后，会将网站的证书信息（证书中包含公钥）传送一份给客户端。
（3）客户端的浏览器与Web服务器开始协商SSL连接的安全等级，也就是信息加密的等级。
（4）客户端的浏览器根据双方同意的安全等级，建立会话密钥，然后利用网站的公钥将会话密钥加密，并传送给网站。
（5）Web服务器利用自己的私钥解密出会话密钥。
（6）Web服务器利用会话密钥加密与客户端之间的通信。
https的优点：
（1）使用HTTPS协议可认证用户和服务器，确保数据发送到正确的客户机和服务器；
（2）HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，要比http协议安全，可防止数据在传输过程中不被窃取、改变，确保数据的完整性。
（3）HTTPS是现行架构下最安全的解决方案，虽然不是绝对安全，但它大幅增加了中间人攻击的成本。
（4） 谷歌曾在2014年8月份调整搜索引擎算法，并称“比起同等HTTP网站，采用HTTPS加密的网站在搜索结果中的排名将会更高”。
https的缺点：
（1）HTTPS协议握手阶段比较费时，会使页面的加载时间延长近50%，增加10%到20%的耗电；
（2）HTTPS连接缓存不如HTTP高效，会增加数据开销和功耗，甚至已有的安全措施也会因此而受到影响；
（3）SSL证书需要钱，功能越强大的证书费用越高，个人网站、小网站没有必要一般不会用。
（4）SSL证书通常需要绑定IP，不能在同一IP上绑定多个域名，IPv4资源不可能支撑这个消耗。
（5）HTTPS协议的加密范围也比较有限，在黑客攻击、拒绝服务攻击、服务器劫持等方面几乎起不到什么作用。最关键的，SSL证书的信用链体系并不安全，特别是在某些国家可以控制CA根证书的情况下，中间人攻击一样可行。
如何在一个不安全的环境中实现安全的数据通信？
要实现数据的安全传输，当然就要对数据进行加密了。
加密使用的是非对称算法，https就是这样来实现的：
- 首先 接收方生成一对密钥，即私钥和公钥；
- 然后，接收方将公钥发送给发送方；
- 发送方用收到的公钥对数据加密，再发送给接收方；
- 接收方收到数据后，使用自己的私钥解密。
公钥加密的数据必须用对应的私钥才能解密，而私钥又只有接收方自己知道，这样就保证了数据传输的安全性。
路由器和交换机比较
- 工作层次不同。交换机是工作在OSI/RM的数据链路层，也就是第二层，而路由器是工作在OSI模型的网络层。由于交换机工作在OSI的第二层（数据链路层），所以它的工作原理比较简单，而路由器工作在OSI的第三层（网络层）；可以得到更多的协议信息，路由器可以作出更加智能的转发决策。
数据转发所依据的对象不同。交换机是利用物理地址或者MAC地址来确定转发数据的目的地址。而路由器则是利用不同网络的ID号来确定数据转发的地址，它们使用IP地址或逻辑地址，而不是MAC地址。MAC地址通常是硬件自带，由网卡生产商来分配，而且已经固化到了网卡中，是不可更改的。而IP地址则通常由网络管理员或系统自动分配。