java面经.pdf

所需积分/C币:50 2019-06-20 11:15:43 17.7MB PDF
234
收藏 收藏
举报

JAVA面经,包含网络数据结构等内容 停止等待协议、连续 ARQ 协议、滑动窗口 一:停止等待协议 停止等待协议是 tcp 保证传输可靠的重要途径,”停止等待”就是指发送完一个 分组就停止发送,等待对方的确认,只有对方确认过,才发送下一个分组. 1:无差错情况:发送方发送分组,接收方在规定时间内收到,并且回复确认.发送 方再次发送…… 2:超时重传有以下三种情况: (1)分组丢失:发送方发送分组,接收方没有收到分组,那么接收方不会发出确认, 只要发送方过一段时间没有收到确认,就认为刚才的分组丢了,那么发送方就会 再次发送. (2):确认丢失:发送方发送成功,接收方接收成功,确认分组也被发送,但是分组 丢失,那么到了等待时间,发送方没有收到确认,又会发送分组过去,此时接收方 前面已经收到了分组,那么此时接收方要做的事就是:丢弃分组,重新发送确认. (3):传送延迟:发送方发送成功,接收方接收成功,确认分组也被发送,没有丢失, 但是由于传输太慢,等到了发送方设置的时间,发送方又会重新发送分组,此时接 收方要做的事情:丢弃分组,重新发送确认. 发送方如果收到两个或者多个确认, 就停止发送,丢弃其他确认. 停
发送窗口前移 11001012002013003014001401500501600601700701800801 已发送 巳发送但 并被确认 未被确认 可发送 不可发送 指针 发送窗口缩小 100101200201300301400401500501600601700701800801 已发送 并被确认 可发送 指针tp://b1og.csdn.net/matr 发 发送端收到了对方对前400字节数据的确认,但对方通知发送端必须把窗口减 小到400字节。现在发送端最多还可发送400字节的数据。 2.拥塞控制 2.1慢开始和拥塞避兔 2.1.1慢开始原理 (1)在主机刚刚开始发送报文段时可先将拥塞窗口cwnd设置为一个最大报文 段MSS的数值 (2)在每收到一个对新的报文段的确认后,将拥塞窗凵增加至多一个MS的 数值。 (3)用这样的方法逐步增大发送端的拥塞窗口cwnd,可以使分组注入到网络 的速率更加合理。 2.1.2实例讲解 拥塞窗口cWnd 线性规律增长 发生超时 24 20进入拥塞避免 进入拥塞避免 16 ssthresh=16 12 -=------------------ == 更新后的 ssthresh 840 指数规律增长 传输次数 0246810121416182022 慢开始|拥塞避免僵开始拥塞避免口cto 注:图中窗凵的单位都是报文段 (1)当TCP连接进行初始化时: 发送窗口:swnd=1 慢开始阈值: ssthresh=16 (2)发送端收到ACK1(确认M,期望收到M1)后,将cwd从1增大到 2,于是发送端可以接着发送M和M2两个报文段(指数增长) (3)接收端发回ACK2和ACK3。发送端每收到一个对新报文段的确认ACK 就把发送端的拥塞窗口加1。现在发送端的cwd从2增大到4,并可发送 M4M6共4个报文段。(指数增长) (4)当swnd> ssthresh,swnd执行拥塞避免算法,swd窗口按线性规律增 长。(加法增大) (5)当发送超时,此时swnd-24 ssthresh=swnd/2=12;(乘法减小) swnd =1 (6)重复地2步。 2.2快重传和快恢复 2.2.1快重传 发送端只要一连收到三个重复的ACK即可断定有分组丢失了,就应立即重传丢 失的报文段而不必继续等待为该报文段设置的重传计时器的超时 2.2.2快恢复 (1)当发送端收到连续三个重复的ACK时,就重新设置慢开始门限 ssthresh。 (2)与慢开始不同之处是swnd不是设置为1,而是设置为 ssthresh+3* MSS (3)若收到的重复的ACK为n个(n>3),则将cwnd设置为 ssthresh+ n*MSS。 (4)若发送窗口值还容许发送报文段,就按拥塞避免算法继续发送报文段。 (5)若收到了确认新的报文段的ACK,就将swnd缩小到 ssthresh。 三次握手,四次挥手 、三次握手 (1)三次握手的详述 首先 Clien端发送连接请求报文, Server段接受连接后回复ACK报文,并为 这次连接分配瓷源。 Client端接收刭ACK报文后也向 Server段发生ACK报 文,并分配资源,这样TCP连接就建立了 客户 服务器 A B 主动打开SH NH)被动打开 SYN LISTEN SYN. SENT SYN= 1, ACK=l, seq =y, ack=x SYN ACK= 1, seq=x+ 1, ack=y +1 RCVD ESTAB LISHED 数据传送 ESTAB LISHED 二二二出二二二二二#二 图531用三次握手建立TCP连接 最初两端的TCP进程都处于CLO0SED关闭状态,A主动打开连接,而B被动打 开连接。(A、B关闭状态CL0SED—B收听状态 LISTEN_—A同步已发送状态 SYN_SENT一—B同步收到状态 SYN-RCVD-—A、B连接已建立状态 ESTABLISHED B的TCP服务器进程先创建传输控制块TCB,准备接受寳户进程的连接请 求。然后服务器进程就处于 LISTEN(收听)状态,等待客户的连接请 求。若有,则作出响应 1)第一次握手:A的TCP客户进程也是首先创建传输控制块TCB,然后 向B发岀连接请求报文段,(首部的同步位SYN=1,初始序号seq=x), (SYN=1的报文段不能携带数据)但要消耗掉一个序号,此时TCP客户 进程进入SYN-SEⅥT(同步已发送)状态 ·2)第二次握手:B收到连接请求报文段后,如同意建立连接,则向A发 送确认,在确认报文段中(SIN=1,ACK=1,确认号ack=x+1,初始序号 seq=y),测试TCP服务器进程进入SYN-RCVD(同步收到)状态; 3)第三次握手:TCP客户进程收到B的确认后,要向B给出确认报文段 (ACK=1,确认号ack=y+1,序号seq=x+1)(初始为seq=x,第二个报 文段所以要+1),ACK报文段可以携情数据,不携带数据则不消耗序 号。TCP连接已绎建立,A进入 ESTABLISHED(凵建立连接)。 当B收到A的确认后,也进入 ESTABLISHED状态 (2)总结三次握手过程: 第一次握手:起初两端都处于 CLOSED关闭状态, Client将标志位SYN 置为1,随机产生一个值seq=x,并将该数据包发送给 Server, Client. 进入 SYN-SENT状态,等待 Server确认 第二次握手: Server收到数据包后由标志位SYN-1得知 Client请求建 立连接, Server将标志位SYN和ACK都置为1,ack=x+1,随机产生一个 值seq=y,并将该数据包发送给 Clien以确认连接请求, Server进入 sN-RCⅦ状态,此时操作系统为该TCP连接分配TCP缓存和变量 第三次握手: Client收到确认后,检查ack是否为x+1,ACK是否为1, 如果正确则将标志位ACK置为1,ack-y+1,并且此时操作系统为该TCP 连接分配TCP缓存和变量,并将该数据包发送给 Server, Server检查 ak是否为y+1,ACK是否为1,如果正确则连接建立成功, Client和 Server进入 ESTABLISHED状态,完成三次握手,随后 Client和 Server 就可以开始传输数据 起初A和B都处于 CLOSED状态一—B创建TCB,处于 LISTEN状态,等待A请求 A创建TCB,发送连接请求(SYN=1,seqx),进入 SYN-SENT状态一—B 收到连接请求,向A发送确认(SYN=ACK=1,确认号ack=x+1,初始序号 seq=y),进入SYN-RCV状态-A收到B的确认后,给B发出确认(ACK-1, ack=y+1,seq=x+1),A进入 ESTABLISHED状态B收到A的确认后,进入 ESTABLISHED状态。 TCB传输控制块 Transmission control block,存储每一个连接中的重要信 息,如TCP连接表,到发送和接收缓存的指针,到重传队列的指针,当前的发 送和接收序号。 (3)为什么A还要发送一次确认呢?可以二次握手吗? 答:主要为了防止已失效的连接请求报文段突然又传送到了B,因而产生 错误。如A发岀连接请求,但因连接请求报文丢失而末收到确认,于是A再重 传一次连接请求。后来收到了确认,建立∫连接。数据传输完毕后,就释放了 连接,A工发出了两个连接请求报文段,其中第一个丢失,第二个到达了B,但 是第一个丢失的报文段只是在某些网络结点长时间滞留了,延误到连接释放以 后的某个时间才到达B,此时B误认为A又发出一次新的连接请求,于是就向A 发出确认报文段,同意建立连接,不采用三次握手,只要B发出确认,就建立 新的连接了,此吋A不理睬B的确认且不发送数据,则B一致等待A发送数 据,浪费瓷源。 4) Server端易受到SYN攻击? 服务器端的资源分配是在二次握手时分配的,而客户端的资源是在完成三次握 手时分恆的,所以服务器容易受到SⅨN洪泛攻击,SYN攻击就是 Client在短时 间内伪造大量不存在的IP地址,并向 Server不断地发送SNN包, Server则回 复确认包,并等待 Client确认,由于源地址不存在,因此 Server需要不断重 发直至超时,这些伪造的SYN包将长时间占用未连接队列,导致正常的SYN请 求因为队列满而被丢弃,从而引起网络拥塞甚至系统瘫痪。 防范SN攻击措施:降低主机的等待吋间使主机尽快的释放半连接的占用,短 时间受到某IP的重复SNN则丢弃后续请求 2、四次挥手 (1)四次挥手的详述 假设 Clien端发起中断连接请求,也就是发送FIN报文。 Server端接到 FIN报文后,意思是说我 Client端没有数据要发给你了",但是如果你还有数 据没有发送完成,则不必急着关闭 Socket,可以继续发送数据。所以你先发送 ACK,"告诉 Client端,你的请求我收到了,但是我还没准备好,请继续你等我 的消息"。这个时候 Client端就进入 FIN WAIT状态,继续等待 Server端的 FIN报文。当 Server端确定数据已发送完成,则向 Clien端发送FIN报文," 告诉 Client端,好了,我这边数据发完了,准备好关闭连接了"。 Client端收 到FIN报文后,"就知道可以关闭连接了,但是他还是不相信网络,怕 Server 端不知道要关闭,所以发送ACK后进入 TIME WAIT状态,如果 Server端没有收 到ACK则可以重传。“, Server端收到ACK后,"就知道可以断开连接了"。 Client端等待了2MSL后依然没有收到回复,则证明 Server端已正常关闭,那 好,我 Client端也可以关闭连接了。Ok,TCP连接就这样关闭了! 客户 服务器 A B ==二=二二=二二二二=二二===二2=2=====================二=== ESTAB 主动关闭 LISHED 数据传送 ESTAB 通知 FIN LISHED 应用 进程 FIN- WAIT-I v ck u CK CLOSE 数据传送 wA被动关闭 FIN WAIT-2 FIN= 1, ACK=1, seq= w, ack=u+ LAST 等待2MSL ACK (LTIME ACK=l, seq=u+ l, ack =w+ I WAIT CLOSED CLOSED 图5-32TCP连接释放的过程 数据传输结束后,通信的双方都可释放连接,A和B都处于 ESTABLISHED状 态。(A、B连接建立状态 ESTABLISHED—A终止等待1状态FIN-WAT-1 B关闭等待状态CL0SE-WATT一—A终止等待2状态 FIN-WAIT-2—B最后确认 状态 LAST-ACK—A时间等待状态TIME-WAIT—一B、A关闭状态CL0SED) 1)A的应用进程先向其TCP发出连接释放报文段(FIN=1,序号 seq=u),并停止再发送数据,主动关闭TCP连接,进入 FIN-WAIT-1 (终止等待1)状态,等待B的确认 2)B收到连接释放报文段后即发出确认报文段,(ACK=1,确认号 ack=u+1,序号seq=),B进入CL0SE-WAIT(关闭等待)状态,此时的 CP处于半关小状态,A到B的连接释放。 3)A收到B的确认后,进入 FIN-WAIT-2(终止等待2)状态,等待B发 出的连接释放报文段 4)B没有要向A发出的数据,B发出连接释放报文段(FIN=1,ACK-1, 序号seq=W,确认号ack=u+1),B进入 LAST-ACK(最后确认)状态,等 待A的确认 5)A收到B的连接释放报文段后,对此发出确认报文段(ACK=1, eq=u+1,ack=W+1),A进入TME-WAIT(时间等待)状态。此时TCP未 释放掉,需要经过时间等待计时器设置的时间2MSL后,A才进入 CLOSED 状态。 (2)总结四次挥手过程: 起初A和B处于 ESTABLISHED状态——A发出连接释放报文段并处于 FIN-WAIT 1状态一—B发出确认报文段且进入CL0 SE-WAIT状态—A收到确认后,进入 FIN-WAIT-2状态,等待B的连接释放报文段一一B没有要向A发出的数据,B 发出连接释放报文段且进入LAST-ACK状态一一A发出确认报文段且进入TIME WAIT状态—一B收到确认报文段后进入CL0SED状态——A经过等待计时器时问 2MSL后,进入CL0SED状态。 (3)为什么A在TIME-WAIT状态必须等待2MSL的时间? MSL最长报文段寿命 Maximum Segment Lifetime,MSL=2 答:两个理由:1)保证A发送的最后一个ACK报文段能够到达B。2)防止 “已失效的连接请求报文段”出现在本连接中。 1)这个ACK报文段有可能丢失,使得处于 LAST-ACK状态的B收不到对 已发送的FIN+ACK报文段的确认,B超时重传 FIN-ACK报文段,而A能 在2MSL时间内收到这个重传的FIN+ACK报文段,接着A重传一次确认, 重新启动2WSL计时器,最后A和B都进入到 CLOSED状态,若A在 TIME-WAIT状态不等待一段时间,而是发送完ACK报文段后立即释放连 接,则无法收到B重传的FIN+ACK报文段,所以不会再发送一次确认报 文段,则B无法正常进入到 CLOSED状态。 2)A在发送完最后一个AK报文段后,再经过2MSL,就可以使本连接持 续的时间内所产生的所有报文段都从网络中消失,使下一个新的连接中 不会出现这种旧的连接请求报文段 (4)为什么连接的时侯是三次握于,关闭的时候却是四次握于? 答:因为当 Server端收到 Client端的SYN连接请求报文后,可以直接发送 SYN+ACK报文。其中ACK报文是用来应答的,SYN报文是用来同步的。但是关闭 连接时,当 Server端收到FIN报文时,很可能并不会立即关闭 SOCKET,所以 只能先回复一个ACK报文,告诉 Client端,"你发的FIN报文我收到了"。只有 等到我 Server端所有的报文都发送完了,我才能发送FIN报文,因此不能一起 发送。故需要四步握手。 TCP与UDP的区别 1、TCP面向连接(如打电话要先拨号建立连接);UDP是无连接的,即发送数据 之前不需要建立连接 2、T(P提供可靠的服务。也就是说,通过TCP连接传送的数据,无差错,不丢 失,不重复,且按序到达;UDP尽最人努力交付,即不保证可靠交付 Tp通过校验和,重传控制,序号标识,滑动窗口、确认应答实现可靠传输。 如丢包时的重发控制,还可以对次序乱掉的分包进行顺序控制。 3、LDP具有较好的实时性,工作效率比TCP高,适用于对高速传输和实时性有 较高的通信或广播通信 4.每条TCP连接只能是点到点的;UDP支持一对,一对多,多对·和多对多 的交互通信 5、TCP对系统资源要求较多,UDP对系统资源要求较少 2、为什么UD有时比TCP更有优势? JD以其简单、传输快的优势,在越来越多场景下取代了TCP,如实时游戏。 (1)网速的提升给LDP的稳定性提供可靠网终保障,丢包率很低,如果使用应 用层重传,能够确保传输的可靠性。 (2)TCP为了实现网络通信的可靠性,使用了复杂的拥塞控制算法,建立了繁 琐的握手过程,由于TCP内置的系统协议栈中,极难对其进行改进。 采用TCP,一旦发生丢包,TCP会将后续的包缓存起来,等前面的包重传并接收 到后再继续发送,延吋会越来越大,基于UDP对实吋性要求较为严格的情况 下,采用自定义重传机制,能够把丟包产生的延迟降到最低,尽量减少网终问 题对游戏性造成影响。 3、UDP和TCP编程步骤也有些不同,如下: TCP TCP编程的服务器端一般步骤是: 1、创建一个 socket,用函数 socket0; SoCKeT SockEtListen socket(AF INET, SOCK STREAM, IPPROTO TCP) 2、设置 socket属性,用函数 setsockopto;求可选 3、绑定IP地址、端口等信息到 socket上,用函数bind(; SOCKET ERROR- bind (SocketListen, (const sockaddr*&addr, sizeof(addr)) 4、开启监听,用函数 listen o SOCKET ERROR listen(SocketListen, 2) 5、接收客户端上来的连接,用函数 accept( SOCKET SocketWaiter= accept(Socketlisten struct sockaddr *addr

...展开详情
试读 127P java面经.pdf
立即下载
限时抽奖 低至0.43元/次
身份认证后 购VIP低至7折
一个资源只可评论一次,评论内容不能少于5个字
您会向同学/朋友/同事推荐我们的CSDN下载吗?
谢谢参与!您的真实评价是我们改进的动力~
上传资源赚钱or赚积分
最新推荐
java面经.pdf 50积分/C币 立即下载
1/127
java面经.pdf第1页
java面经.pdf第2页
java面经.pdf第3页
java面经.pdf第4页
java面经.pdf第5页
java面经.pdf第6页
java面经.pdf第7页
java面经.pdf第8页
java面经.pdf第9页
java面经.pdf第10页
java面经.pdf第11页
java面经.pdf第12页
java面经.pdf第13页
java面经.pdf第14页
java面经.pdf第15页
java面经.pdf第16页
java面经.pdf第17页
java面经.pdf第18页
java面经.pdf第19页
java面经.pdf第20页

试读结束, 可继续阅读

50积分/C币 立即下载