• 注册
  • Android博客 Android博客 关注:0 内容:1372

    计算机网络面试(五)之运输层及常见面试题

  • 查看作者
  • 打赏作者
  • 当前位置: 职业司 > Android开发 > Android博客 > 正文
    • Android博客
      • 概述
      • 多路复用 多路分解
      • 无连接运输:UDP
        • 特点
        • 报文
        • UDP和TCP的不同
      • 面向连接的运输:TCP
        • 特点
        • MSS
        • 报文
        • 连接管理
          • 三次握手
          • 为什么需要三次握手而不是两次握手?
        • 四次挥手
          • 为什么客户端最后还要等待2MSL?
          • 为什么建立连接是三次握手,关闭连接却是四次挥手呢?
      • 可靠性传输
        • ARQ
          • 连续ARQ
          • 停止等待ARQ
        • 滑动窗口
      • 流量控制
      • 拥塞控制 (TCP conggestion control algorithm)
        • 慢开始
        • 拥塞避免
        • 快重传 和 快恢复 (FRR, fast retransmit and recovery)
      • 应用层协议使用运输层协议一些分类
      • 问题
        • Q:大文件下载为什么多线程会快一些?
        • Q:你猜一个 TCP 连接上面能发多少个 HTTP 请求?
        • Q:为什么TCP建立连接协议是三次握手,而关闭连接却是四次握手呢?
        • TCP报文的长度在TCP三次握手中那一次确定的?
        • Q:Web页面的请求历程

      概述

      功能: 运输层协议为运行在不同的主机上的应用进程提供了逻辑通信功能。网络层提供了主机之间的逻辑通信。

      多路复用 多路分解

      多路分解:将运输层报文段中的数据交付到正确的套接字
      多路复用:源主机从不同套接字中收集数据块,并为每个数据块封装首部信息生成报文段,传递到网络层,这些工作成为多路复用。

      无连接运输:UDP

      特点

      • 无连接的
        发送方和接收方的运输层实体之间没有握手。不会引入建立连接的时延。

      • 无连接状态
        TCP需要在端系统中维护连接状态,包括接收和发送给缓存、拥塞控制参数以及序号和确认号的参数。

      • 分组首部开销小

      • 关于何时、发送什么数据的应用层控制更为精细
        UDP打包即发出,没有TCP的拥塞控制等限制,TCP可靠交付可能时延比较大。

      • 面向数据报

      为什么说TCP报文段是面向字节流的,UDP是面向数据报的?

      面向报文的传输方式是应用层交给UDP多长的报文,UDP就照样发送,即一次发送一个报文。因此,应用程序必须选择合适大小的报文。若报文太长,则IP层需要分片,降低效率。若太短,会是IP太小。UDP对应用层交下来的报文,既不合并,也不拆分,而是保留这些报文的边界。这也就是说,应用层交给UDP多长的报文,UDP就照样发送,即一次发送一个报文。

      虽然应用程序和TCP的交互是一次一个数据块(大小不等),但TCP把应用程序看成是一连串的无结构的字节流。TCP有一个缓冲,当应用程序传送的数据块太长,TCP就可以把它划分短一些再传送。如果应用程序一次只发送一个字节,TCP也可以等待积累有足够多的字节后再构成报文段发送出去。

      在TCP建立连接前两次握手的SYN报文中选项字段的MSS值,通信双方商定通信的最大报文长度。如果应用层交付下来的数据过大,就会对数据分段,然后发送;否则通过滑动窗口协议来控制通信双发的数据。

      报文

      计算机网络面试(五)之运输层及常见面试题

      提供端到端的差错检测,但是对差错恢复无能为力,有些UDP的实现是丢弃受损的报文段,其他实现是将受损的报文段交给应用程序并给出警告。

      UDP和TCP的不同

      计算机网络面试(五)之运输层及常见面试题

      计算机网络面试(五)之运输层及常见面试题

      面向连接的运输:TCP

      特点

      • 面向连接可靠运输
      • 全双工服务
        进程A和B建立连接,应用层数据可在从进程B流向进程A的同时,也从进程A流向进程B。
      • 点对点
        连接在单个发送方和单个接收方之间。
      • 面向字节流

      维基百科TCP

      MSS

      TCP三次握手初期设置发送缓存,TCP从发送缓存里取数据,从缓存取出并放到报文段的数据数量受限于 最大报文段长度(Maximum Segment Size, MSS)

      MSS通常根据MTU设置。MSS保证一个TCP报文段适合MTU(报文+TCP/IP首部)。MSS典型值 1460字节。

      一句话,MSS就是TCP报文段所允许传送的最大数据部分的长度,如果上层交付下来的数据太大,就对其进行数据分块。这个分块过程是在运输层完成的,在接收端的运输层对分块的TCP报文段的数据部分进行重组。

      注意:这个MSS指的是TCP报文段中数据部分的最大长度,并不是整个TCP报文段长度。整个TCP报文段长度 = TCP首部长度 + TCP数据部分长度。

      MSS的值是在TCP三次握手建立连接的过程中,经通信双方协商确定的。我们都知道链路层使用以太网的话,IP层的MTU是1500 byte,这样去掉IP数据报首部(20 byte),在去掉TCP首部(20 byte)后为1460 byte,此时在默认情况下TCP“选项”字段的MSS值为1460 byte = 1500 - 20 - 20。在 Internet 标准中,IP层的MTU是576 byte,那么此时TCP“选项”字段的MSS值为536 byte = 576 - 20 - 20。

      • TCP中报文段大小(MSS)、MTU

      TCP报文的长度在TCP三次握手中那一次确定的?
      MSS值只会出现在SYN报文中(不要问我为什么,我也不知道为什么只出现SYN报文中),即SYN=1时,才会有MSS字段值。当客户端想要以TCP方式从服务器端下载数据时,

      • (1)首先客户端会发送一个SYN请求报文,这个SYN报文的“选项”字段中会有MSS值(MSS = MTU - IP首部长度 - TCP首部长度)。该MSS值是为了告知对方最大的发送数据大小。
      • (2)当服务器端收到SYN报文后,会向请求端返回SYN+ACK(同步确认报文)报文,其中的“选项”字段也会有MSS值。
      • (3)通信双方选择SYN和SYN+ACK报文中最小的MSS最为此次TCP连接的MSS,从而达到通信双发协商MSS的效果。

      综上,可以回答开始时的问题。在第二次握手后就可以确定TCP中最大传输报文(MSS)大小。

      • 以太网与互联网有什么区别? - 沙雕的回答 - 知乎

      报文

      TCP首部通常20字节。

      计算机网络面试(五)之运输层及常见面试题计算机网络面试(五)之运输层及常见面试题

      计算机网络面试(五)之运输层及常见面试题计算机网络面试(五)之运输层及常见面试题

      连接管理

      三次握手

      参考 TCP的三次握手与四次挥手

      计算机网络面试(五)之运输层及常见面试题计算机网络面试(五)之运输层及常见面试题

      • TCP服务器进程先创建传输控制块TCB,时刻准备接受客户进程的连接请求,此时服务器就进入了LISTEN(监听)状态;
      • TCP客户进程也是先创建传输控制块TCB,然后向服务器发出连接请求报文,这是报文首部中的同部位SYN=1,同时选择一个初始序列号 seq=x ,此时,TCP客户端进程进入了 SYN-SENT(同步已发送状态)状态。TCP规定,SYN报文段(SYN=1的报文段)不能携带数据,但需要消耗掉一个序号。
      • TCP服务器收到请求报文后,如果同意连接,则发出确认报文。确认报文中应该 ACK=1,SYN=1,确认号是ack=x+1,同时也要为自己初始化一个序列号 seq=y,此时,TCP服务器进程进入了SYN-RCVD(同步收到)状态。这个报文也不能携带数据,但是同样要消耗一个序号。
      • TCP客户进程收到确认后,还要向服务器给出确认。确认报文的ACK=1,ack=y+1,自己的序列号seq=x+1,此时,TCP连接建立,客户端进入ESTABLISHED(已建立连接)状态。TCP规定,ACK报文段可以携带数据,但是如果不携带数据则不消耗序号。
      • 当服务器收到客户端的确认后也进入ESTABLISHED状态,此后双方就可以开始通信了。

      为什么需要三次握手而不是两次握手?

      一句话,主要防止已经失效的连接请求报文突然又传送到了服务器,从而产生错误。

      如果使用的是两次握手建立连接,假设有这样一种场景,客户端发送了第一个请求连接并且没有丢失,只是因为在网络结点中滞留的时间太长了,由于TCP的客户端迟迟没有收到确认报文,以为服务器没有收到,此时重新向服务器发送这条报文,此后客户端和服务器经过两次握手完成连接,传输数据,然后关闭连接。此时此前滞留的那一次请求连接,网络通畅了到达了服务器,这个报文本该是失效的,但是,两次握手的机制将会让客户端和服务器再次建立连接,这将导致不必要的错误和资源的浪费。

      如果采用的是三次握手,就算是那一次失效的报文传送过来了,服务端接受到了那条失效报文并且回复了确认报文,但是客户端不会再次发出确认。由于服务器收不到确认,就知道客户端并没有请求连接。

      也可以这样理解,
      第一次 只能确认发送方发送正常
      第二次 能确认接收方发送接收正常,发送方发送正常,但还无法确认发送方接收正常
      第三次 能确认双方接收发送都正常

      四次挥手

      计算机网络面试(五)之运输层及常见面试题计算机网络面试(五)之运输层及常见面试题

      • 客户端进程发出连接释放报文,并且停止发送数据。释放数据报文首部,FIN=1,其序列号为seq=u(等于前面已经传送过来的数据的最后一个字节的序号加1),此时,客户端进入FIN-WAIT-1(终止等待1)状态。 TCP规定,FIN报文段即使不携带数据,也要消耗一个序号。
      • 服务器收到连接释放报文,发出确认报文,ACK=1,ack=u+1,并且带上自己的序列号seq=v,此时,服务端就进入了CLOSE-WAIT(关闭等待)状态。TCP服务器通知高层的应用进程,客户端向服务器的方向就释放了,这时候处于半关闭状态,即客户端已经没有数据要发送了,但是服务器若发送数据,客户端依然要接受。这个状态还要持续一段时间,也就是整个CLOSE-WAIT状态持续的时间。
      • 客户端收到服务器的确认请求后,此时,客户端就进入FIN-WAIT-2(终止等待2)状态,等待服务器发送连接释放报文 (在这之前还需要接受服务器发送的最后的数据)。
      • 服务器将最后的数据发送完毕后,就向客户端发送连接释放报文,FIN=1,ack=u+1,由于在半关闭状态,服务器很可能又发送了一些数据,假定此时的序列号为seq=w,此时,服务器就进入了LAST-ACK(最后确认)状态,等待客户端的确认。
      • 客户端收到服务器的连接释放报文后,必须发出确认,ACK=1,ack=w+1,而自己的序列号是seq=u+1,此时,客户端就进入了TIME-WAIT(时间等待)状态。注意此时TCP连接还没有释放,必须经过2*MSL(最长报文段寿命)的时间后,当客户端撤销相应的TCB后,才进入CLOSED状态。
      • 服务器只要收到了客户端发出的确认,立即进入CLOSED状态。同样,撤销TCB后,就结束了这次的TCP连接。可以看到,服务器结束TCP连接的时间要比客户端早一些。

      为什么客户端最后还要等待2MSL?

      MSL(Maximum Segment Lifetime),TCP允许不同的实现可以设置不同的MSL值。

      第一,保证客户端发送的最后一个ACK报文能够到达服务器,因为这个ACK报文可能丢失,站在服务器的角度看来,我已经发送了FIN+ACK报文请求断开了,客户端还没有给我回应,应该是我发送的请求断开报文它没有收到,于是服务器又会重新发送一次,而客户端就能在这个2MSL时间段内收到这个重传的报文,接着给出回应报文,并且会重启2MSL计时器。

      第二,防止类似与“三次握手”中提到了的“已经失效的连接请求报文段”出现在本连接中。客户端发送完最后一个确认报文后,在这个2MSL时间中,就可以使本连接持续的时间内所产生的所有报文段都从网络中消失。这样新的连接中不会出现旧连接的请求报文。

      • [为什么TCP4次挥手时等待为2MSL? - 车小胖的回答 - 知乎](

      www.zhihu.com/question/67…)

      为什么建立连接是三次握手,关闭连接却是四次挥手呢?

      建立连接的时候, 服务器在LISTEN状态下,收到建立连接请求的SYN报文后,把ACK和SYN放在一个报文里发送给客户端。
      而关闭连接时,服务器收到对方的FIN报文时,仅仅表示对方不再发送数据了但是还能接收数据,而自己也未必全部数据都发送给对方了,所以己方可以立即关闭,也可以发送一些数据给对方后,再发送FIN报文给对方来表示同意现在关闭连接,因此,己方ACK和FIN一般都会分开发送,从而导致多了一次。

      可靠性传输

      ARQ

      ARQ(Automatic Repeat reQuest)自动重传请求协议 是OSI模型数据链路层和运输层的错误纠正协议之一。通过确认超时这两个机制,在不可靠服务的基础上实现可靠的信息传输。包括停止等待ARQ协议连续ARQ协议

      TCP使用的是连续ARQ协议。

      ARQ协议包括这些机制

      • 差错检测
      • 接收方反馈 肯定确认ACK、否定确认NCK
        • 累计确认: 接收方不必对收到的分组逐个发送确认。而是在收到几个分组后,对按序到达的最后一个分组发送确认。
      • 重传 超时重传等

      ARQ协议对错误纠正的方法是:

      • 丢弃已经接收的含有错误的数据包。
      • 向发送点请求重新发送数据包。

      可参考维基百科ARQ

      连续ARQ

      为了克服停止并等待ARQ协议长时间等待ACK的缺点。这个协议会连续发送一组数据包(流水线传输),然后再等待这些数据包的ACK.

      流水线传输就是发送方可以连续发送多个分组,不必每发完一个分组就停下来等待对方确认。连续ARQ通常结合滑动窗口协议使用。

      回退N重传(Go-Back-N)

      • 接收点丢弃从第一个没有收到的数据包开始的所有数据包。
      • 发送点收到NACK后,从NACK中指明的数据包开始重新发送。
        • 有缺点:不能正确的向发送方反映出接收方已经正确收到的所以分组的信息。
        • 比如发送方发送了前5个分组,而中间的第3个分组丢失了,这时候接收方只能对前2个发出确认。而不知道后面3个分组的下落,因此只能把后面的3个分组都重传一次,

      选择重传(Selective Repeat)

      • 发送点连续发送数据包但对每个数据包都设有个一个计时器。
      • 当在一定时间内没有收到某个数据包的ACK时,发送点只重新发送那个没有ACK的数据包。

      停止等待ARQ

      停止并等待协议的工作原理如下:

      • 发送点对接收点发送数据包,然后等待接收点回复ACK并且开始计时。
      • 在等待过程中,发送点停止发送新的数据包。
      • 当数据包没有成功被接收点接收时候,接收点不会发送ACK.这样发送点在等待一定时间后,重新发送数据包。
      • 反复以上步骤直到收到从接收点发送的ACK.

      缺点

      • 较长的等待时间导致低的数据传输速度

      滑动窗口

      发送方维护发送窗口,接收方维护接收窗口。

      计算机网络面试(五)之运输层及常见面试题

      计算机网络面试(五)之运输层及常见面试题规则:

      • (1)凡是已经发送过的数据,在未收到确认之前,都必须暂时保留,以便在超时重传时使用。
      • (2)只有当发送方A收到了接收方的确认报文段时,发送方窗口才可以向前滑动几个序号。
      • (3)当发送方A发送的数据经过一段时间没有收到确认(由超时计时器控制),就要使用回退N步协议,回到最后接收到确认号的地方,重新发送这部分数据。

      发送窗口中有四个概念

      • 已发送并收到确认的数据(不在发送窗口和发送缓冲区之内)
      • 已发送但未收到确认的数据(位于发送窗口之内)
      • 允许发送但尚未发送的数据(位于发送窗口之内)
      • 发送窗口之外的缓冲区内暂时不允许发送的数据。

      接收窗口中也有四个概念

      • 已发送确认并交付主机的数据(不在接收窗口和接收缓冲区之内)
      • 未按序收到的数据(位于接收窗口之内)
      • 允许的数据(位于接收窗口之内)
      • 不允许接收的数据(位于发送窗口之内)。

      流量控制

      一条TCP连接每一侧主机都为该连接设置了接受缓存。TCP连接收到正确、按序的字节后,它就将数据放入接收缓存。应用程序从该缓存读数据,但不是数据刚到就读取。为了防止发送方发送太多太快,导致接收缓存溢出,TCP提供流量控制服务(flow-control service)

      使用滑动窗口协议

      发送方维护 接收窗口(rwnd) 的变量进行流量控制。

      把rwnd的值放在TCP报文 接收窗口字段。

      举例:

      拥塞控制 (TCP conggestion control algorithm)

      和流量控制相似,都是控制发送方发送的速度,但是目标不一样,流量控制是为了防止接收方接收缓存溢出,拥塞控制是因为网络发生拥堵而降低发送速度。

      TCP的拥塞控制采用了四种算法,即 慢开始 、 拥塞避免 、快重传 和 快恢复。

      可参考

      • TCP的拥塞控制
      • 浅谈 TCP 拥塞控制算法

      慢开始

      发送方维持一个叫做 拥塞窗口cwnd(congestion window) 的状态变量。拥塞窗口的大小取决于网络的拥塞程度,并且动态地在变化。发送方让自己的发送窗口等于拥塞窗口,另外考虑到接受方的接收能力,发送窗口可能小于拥塞窗口。

      慢开始算法的思路就是,不要一开始就发送大量的数据,先探测一下网络的拥塞程度,也就是说由小到大逐渐增加拥塞窗口的大小 (乘法增长)

      这里用报文段的个数的拥塞窗口大小举例说明慢开始算法,实时拥塞窗口大小是以字节为单位的。如下图:

      拥塞避免

      为了防止cwnd增长过大引起网络拥塞,还需设置一个 慢开始门限ssthresh状态变量。ssthresh的用法如下:

      • 当cwnd < ssthresh时,使用慢开始算法。
      • 当cwnd > ssthresh时,改用拥塞避免算法。
      • 当cwnd = ssthresh时,慢开始与拥塞避免算法任意。

      无论是在慢开始阶段还是在拥塞避免阶段,只要发送方判断网络出现拥塞,就把 慢开始门限设置为出现拥塞时的发送窗口大小的一半。然后把拥塞窗口设置为1,执行慢开始算法。

      快重传 和 快恢复 (FRR, fast retransmit and recovery)

      快重传要求接收方在收到一个失序的报文段后就立即发出重复确认(为的是使发送方及早知道有报文段没有到达对方)而不要等到自己发送数据时捎带确认。快重传算法规定,发送方只要一连收到三个重复确认就应当立即重传对方尚未收到的报文段,而不必继续等待设置的重传计时器时间到期(没有FRR,如果数据包丢失了,TCP 将会使用定时器来要求传输暂停。在暂停的这段时间内,没有新的或复制的数据包被发送)。

      • 维基百科-TCP拥塞控制

      快速重传(Fast retransmit)是对TCP发送方降低等待重发丢失分段用时的一种改进。TCP发送方每发送一个分段都会启动一个超时计时器,如果没能在特定时间内接收到相应分段的确认,发送方就假设这个分段在网络上丢失了,需要重发。这也是 TCP 用来估计 RTT 的测量方法。

      重复确认(duplicate cumulative acknowledgements,DupAcks)就是这个阶段的基础,其基于以下过程:如果接收方接收到一个数据分段,就会将该分段的序列号加上数据字节长的值,作为分段确认的确认号,发送回发送方,表示期望发送方发送下一个序列号的分段。但是如果接收方提前收到更下一个序列号的分段——或者说接收到无序到达的分段,即之前期望确认号对应的分段出现接收丢失——接收方需要立即使用之前的确认号发送分段确认。此时如果发送方收到接收方相同确认号的分段确认超过1次,并且该对应序列号的分段超时计时器仍没超时的话,则这就是出现重复确认,需要进入快速重传。

      快重传配合使用的还有快恢复算法,有以下两个要点:

      • ①当发送方连续收到三个重复确认时,就执行“乘法减小”算法,把ssthresh门限减半。但是接下去并不执行慢开始算法。
      • ②考虑到如果网络出现拥塞的话就不会收到好几个重复的确认,所以发送方现在认为网络可能没有出现拥塞。所以此时不执行慢开始算法,而是将cwnd设置为ssthresh的大小,然后执行拥塞避免算法。

      应用层协议使用运输层协议一些分类

      • SSH
        端口号22,TCP
      • MYSQL
        端口号 3306 TCP

      0~1023是周知端口号,受限制,给HTTP或者FTP这种预留使用的。

      Q:大文件下载为什么多线程会快一些?

      • 为什么多线程下载能加速?
      • 多线程下载一个大文件的速度更快的真正原因是什么?
      • 决定用户下载大文件速度快慢的终极因素,在于用户下载进程实时抢占网络带宽的大小。其它的因素与它相比,可以忽略不计。
      • 用户进程实时抢占的带宽 ≤实时网络可用带宽 Forever!!!
      • 传统的TCP流量探测机制有一个非常致命的缺陷:一旦检测到有丢包,立马将发送速率降为1/2。降速1/2后,如果没有丢包,将会在1/2速率的基础上,按照固定的增长值(线性增长),加大发送的速率。接下来就会一直按照这个节奏到达丢包的那一刻(实时可用带宽)为止。然后再1/2降速,循环往复,直到文件下载结束。
      • 在任意时刻,有的线程处于丢包被罚1/2降速,有的线程处于2倍增速阶段(Slow Start),而有的线程处于线性增长阶段。通过多个线程的下载速率的加权平均,得到的是一根相对平滑的下载曲线。这条平滑曲线在大多数时候应该位于单线程下载速率的上方。这就是多线程下载速率更有优势的体现。

      Q:你猜一个 TCP 连接上面能发多少个 HTTP 请求?

      • 知乎: 你猜一个 TCP 连接上面能发多少个 HTTP 请求
      • 哈,你猜一个 TCP 连接上面能发多少个 HTTP 请求?

      Q:为什么TCP建立连接协议是三次握手,而关闭连接却是四次握手呢?

      • 为什么TCP建立连接协议是三次握手,而关闭连接却是四次握手呢?

      Q:TCP报文的长度在TCP三次握手中那一次确定的?

      我们知道TCP传输可靠性的保证中有一点是:TCP会将应用层交付下来的数据分为TCP认为最适合发送的数据块。这里的数据块大小就是MSS(maximum segment size最大分段长度)。MSS字段位于TCP首部中的选项字段。

      一句话,MSS就是TCP报文段所允许传送的最大数据部分的长度,如果上层交付下来的数据太大,就对其进行数据分块。这个分块过程是在运输层完成的,在接收端的运输层对分块的TCP报文段的数据部分进行重组。

      注意:这个MSS指的是TCP报文段中数据部分的最大长度,并不是整个TCP报文段长度。整个TCP报文段长度 = TCP首部长度 + TCP数据部分长度。

      二、通信双方如何协商MSS
      MSS的值是在TCP三次握手建立连接的过程中,经通信双方协商确定的。我们都知道链路层使用以太网的话,IP层的MTU是1500 byte,这样去掉IP数据报首部(20 byte),在去掉TCP首部(20 byte)后为1460 byte,此时在默认情况下TCP“选项”字段的MSS值为1460 byte = 1500 - 20 - 20。在 Internet 标准中,IP层的MTU是576 byte,那么此时TCP“选项”字段的MSS值为536 byte = 576 - 20 - 20。

      以上是默认情况下一个TCP报文段中的MSS值,下面我们详细说明MSS值的确定过程。

      MSS值只会出现在SYN报文中(不要问我为什么,我也不知道为什么只出现SYN报文中),即SYN=1时,才会有MSS字段值。当客户端想要以TCP方式从服务器端下载数据时,

      (1)首先客户端会发送一个SYN请求报文,这个SYN报文的“选项”字段中会有MSS值(MSS = MUT - IP首部长度 - TCP首部长度)。该MSS值是为了告知对方最大的发送数据大小。

      (2)当服务器端收到SYN报文后,会向请求端返回SYN+ACK(同步确认报文)报文,其中的“选项”字段也会有MSS值。

      (3)通信双方选择SYN和SYN+ACK报文中最小的MSS最为此次TCP连接的MSS,从而达到通信双发协商MSS的效果。

      综上,可以回答开始时的问题。在第二次握手后就可以确定TCP中最大传输报文(MSS)大小。

      三、MTU
      MTU是最大传输单元,这个根据由具体的网络决定的,如以太网MTU=1500,Internet的MTU=576。

      Q:Web页面的请求历程

      • Web页面的请求历程

      请登录之后再进行评论

      登录

      手机阅读天地(APP)

      • 微信公众号
      • 微信小程序
      • 安卓APP
      手机浏览,惊喜多多
      匿名树洞,说我想说!
      问答悬赏,VIP可见!
      密码可见,回复可见!
      即时聊天、群聊互动!
      宠物孵化,赠送礼物!
      动态像框,专属头衔!
      挑战/抽奖,金币送不停!
      赶紧体会下,不会让你失望!
    • 实时动态
    • 签到
    • 做任务
    • 发表内容
    • 偏好设置
    • 到底部
    • 帖子间隔 侧栏位置:
    • 还没有账号?点这里立即注册