java后台面试之计算机网络问题集锦
Posted yinbiao
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了java后台面试之计算机网络问题集锦相关的知识，希望对你有一定的参考价值。
1）原理不同
http协议运行于TCP之上，明文传输，客户端和服务端都无法验证对方身份
https是身披SSL（Secure Socket Layer）外壳的http，运行于SSL之上，是添加了加密和认证机制的http
2）端口不同：http使用的是80端口，https使用的是443端口
3）资源消耗不同：和http通信相比，https会由于加密解密出来消耗更多的cpu资源和内存
4）开销：https通信需要证书，证书需要向认证机构购买
httpd的加密机制是一种共享密钥加密和公开公钥加密并用的混合加密机制
对称密钥加密是指加密和解密使用同一个密钥的方式，这种方式存在的最大问题就是密钥的发送问题，即任何将密钥安全的发送给对方，而非对称密钥加密是指使用一对非对称密钥，即公钥和私钥，公钥可以随意发布，但是私钥只有自己知道，发送密文的一方使用对方的公钥进行加密处理，对方接收到加密信息之后，使用自己的私钥进行解密
由于非对称加密的方式不需要发送用来解密的私钥，所以可以保证安全性，但是和对称加密比起来，它非常的慢，所以我们还是要用对称加密的方式发送信息，加密的密钥可以通过非对称加密的方式发送出去
1)三次握手（我要和你建立连接，你真的要和我建立连接吗？我真的要和你建立连接，成功）
*第一次握手：客户端：发送序号200（随机的），标志位SYN=1
*第二次握手（建立接收缓冲区）：服务器端：发送序号500（随机的），确认序号200+1，标志位SYN=1，ACK=1
*第三次握手（建立发送缓冲区）：客户：发送序号=201，确认序号=500+1，标志位ACK=1
要发送的发送序号=上一次接收到的确认序号
要发送的确认序号=上一次的发送序号+1
2）四次挥手（我要和你断开连接；好吧，断吧，但要先等我发完剩余数据；剩余数据发完了，我也要和你断开连接；好吧，断吧）
*第一次挥手：客户：发送序号=200，标志位FIN=1
*第二次挥手（释放接收缓冲区）：服务端：发现接收到的FIN=1，就发送序号=500，确认序号=200+1，标志位ACK=1
*第三次挥手（释放发送缓冲区）：服务器：发送序号=300，确认序号=200+1，标志位FIN=1，ACK=1
*第四次挥手：客户：发送序号=201，确认序号=300+1，标志位ACK=1
为了防止已经失效的连接请求报文突然又传送到了服务器端（网络堵塞的原因）
如果客户端发出的连接请求报文并未丢失而是在某个网络结点长时间堵塞了，导致延误到连接释放以后的某个时间才到达服务器，这时服务器误以为是客户端发出了一个新的连接请求，于是就向客户端发送确认数据包，同意建立连接，如果不采用三次握手，那么只要服务器端发送确认数据包，连接就建立成功了，由于客户端并未发出连接请求，所以不会理睬服务器的确认，也不与服务器通信，而这个时候服务器一直在等待客户端发送数据，这样服务器就白白浪费了资源，如果采用三次握手，那么服务器端密钥收到来自客户端的确认，就知道客户端并没有请求建立连接，就不会建立连接
三次和四次的区别就在于服务器连续给客户端发了两个报文，那把这两个报文合并成一个不可以吗？为什么呢？答案是不可以，首先客户端发来请求断开连接的报文，假设这个时候服务器端仍然在发送报文（因为是全双工），如果是三次挥手，那么服务器只会确认客户的断开请求，客户端不会说我还有数据没有发送完，你要等等我，这样会导致客户端接收的数据不完整，如果是四次挥手，那么服务器接收到客户的断开请求，会先说可以断开，但是你要先等我发送完剩余的数据，然后说我剩余的数据发送完了，我要和你断开连接
挥手过程之所以比握手过程多一次，就是因为握手过程只需要处理连接，而挥手过程需要处理连接和数据！！
TCP提供一种面向连接的，可靠的字节流服务，其中，面向连接意味着两个使用TCP的应用在彼此交换数据之前必须先建立一个TCP连接，在一个TCP中，仅有两方进行彼此通信，而字节流服务意味着两个应用程序通过TCP连接交换8比特字节构成的字节流，TCP不在字节流中插入记录标识符
对于可靠性，TCP通过以下方式保证：
1）数据包校验：目的是检测数据在传输过程中的任何变化，若校验包出错，则丢弃报文段并且不给出响应，这时TCP数据发送端超时重发数据
2）对失序数据包重排序：既然TCP报文段作为IP数据报来传输，而IP数据报的到达可能会失序，因此TCP报文段到达也可能会失序，TCP将失序数据重排序才交给应用层
3）丢弃重复数据
4）应答机制：当TCP收到一个报文就发送一个确认信号
5）超时重传：一个TCP报文段发送出去后，启动计时器，到达某个时间没有收到确认信号就重传该报文段
6）流量控制：TCP连接的每一方都有一块固定大小的缓冲空间，TCP的接收端只允许另一端发送接收端缓冲区能容纳的数据，这样可以防止较快主机使得较快主机缓冲区溢出，同样也能避免网络拥塞，TCP使用的流量控制协议就是可变大小的滑动窗口协议
服务器会为每个请求创立一个连接，并向其发送确认报文，然后等待客户端进行确认
1）DDOS攻击
*客户端向服务端发送请求数据包
*服务端向客户端发送确认数据包
*客户端不向服务端发送确认数据包，服务器一直等待客户端的确认
2）DDOS攻击的预防（没有办法根治，除非不使用TCP）
*限制同时打开的SYN半连接数目
*缩短SYN半连接的Time Out时间
*关闭不必要服务
get和post是http所属的方法，而http又是基于TCP/IP实现的，所以get和post的底层都是TCP/IP协议，只不过http定义的规则和浏览器的限制导致他们在应用上存在一定的区别，最重要的区别就是get产生一个TCP数据包，而post产生两个TCP数据包，对于get的请求，浏览器会把浏览器的header和data一起发送出去，服务器响应200，对于post，浏览器先发送header，浏览器响应100，浏览器再发送data，服务器响应200，也就是说get只需要汽车跑一趟就把货送到了，而post需要跑两趟，第一趟先去和服务器打个招呼告诉它我等下要送货过来，开门迎接我，第二趟就是把货送过去，据研究，在网络环境好的情况下，发一次包的时间和发两次包的时间查基本可以无视，而在网络环境差的情况下，两次包的TCP在验证数据包完整性上有很大的优势，所以不推荐使用get来优化性能，当然，并不是所有的浏览器都会在post中发两次tcp包，火狐浏览器就只发一次
下面我们看看get和post应用上的区别：
*get的参数通过URL传递，post放在request body中
*get在URL中的参数是有长度限制的，而post没有
*get只能进行URL编码，而post支持多种
*get只接受ASSIC字符，而post没有限制
*post比get安全，因为get的参数暴露在URL中
1）TCP面向连接，而UDP是无连接的
2）TCP可靠，UDP不可靠
3）TCP只支持点对点通信，而UDP支持1对1，1对多，多对1，多对多的通信模式
4）TCP是面向字节流的，UDP是面向报文的
5）TCP有拥塞控制，UDP没有拥塞控制，适合媒体通信
6)TCP首部开销（20字节）比UDP首部开销（8个字节）要大
拥塞控制就是防止过多的数据注入网络，造成网络堵塞，拥塞控制和流量控制不同，拥塞控制是一个全局性过程，而流量控制是点对点通信的控制，拥塞控制的方法主要有以下5种：
1）拥塞窗口：动态窗口，和网络拥塞程度有关，网络拥塞程度大，拥塞窗口就小
2）慢启动：不要一开始就发送大量数据，先探测一下网络的拥塞程度，也就是说从小到大逐渐增加拥塞窗口的大小
3）拥塞避免（AMDI：加法增大乘法减小）：让拥塞窗口缓慢增大，每经过一个往返时间就将拥塞窗口+1,缓慢增大拥塞窗口
4）快重传：发送方只要一收到三个重复的确认就应该立即重传对方并未收到的报文段，而不必继续等待重传计时器到达重传时间，快重传并不是取消重传计时器，而是在某些情况下更早的重传丢失的报文
5）快恢复：根据收到的重复的ACK的多少调节慢开始门限值ssthresh
1）浏览器查询DNS，获得域名对应的IP地址
*先从浏览器缓存找ip，因为浏览器会缓存DNS记录一段时间
*如果没有找到，再从Host文件查找是否有该域名对应的IP
*如果没有找到，再从路由器缓存找
*如果没有找到，再从DNS缓存找
*如果都没有找到，就从浏览器域名服务器向根域名服务器查找，没有找到就继续迭代，知道找到为止
2）浏览器获得IP地址后，浏览器向服务器请求连接，发起三次握手
3）连接建立起来后，浏览器向服务器发送http请求
4）服务器接收到这个请求，并根据路径参数映射到特定的请求处理器进行处理，并将视图以及相应的结果返回给浏览器
5）浏览器解析并渲染视图，若遇到对js，css文件以及静态图片资源的引用，重复上述步骤向服务器请求资源
6）浏览器根据请求到的资源，数据渲染页面，最终向用户呈现
1）TCP对应的应用层协议
*FTP：文件传输协议，21端口
*Telnet：远程登陆协议，23端口
*SMTP：简单邮件传送协议，25端口
*POP3：和SMTP对应，POP3用于接收邮件，110端口
*HTTP：超文本传输协议，80端口
2）UDP对应的应用层协议
*DNS：域名解析协议，53端口
*SNMP：简单网络管理协议，161端口
*TFTP:简单文件传输协议，69端口
以上是关于java后台面试之计算机网络问题集锦的主要内容，如果未能解决你的问题，请参考以下文章