p***p
发帖数: 559 | 1 客户端和服务器之间试图建立TCP连接，当然经过一系列防火墙和路由器和
loadbalancer。TCP三路握手，前两个都顺利通过，可是从客户端发出的第三个ACK却消
失在网络中。请问会是什么原因呢？难道防火墙会专门阻挡第三个？ |
|
i*****o
发帖数: 1714 | 2 害的我几个晚上没睡个好觉！
一直在用linux好久，时不时碰到个小问题，可从来没有到让人气愤的的地步，毕竟
linux好处多多，一点小问题就算了。可这次太让我忍无可忍，不得不上来骂几句。
话说偶在做一个voip的app，用linux做中转。linux上的code很简单，就是每20ms来个
50字节，从一个socket放到另外一个socket，这对偶做了n年网络工程师的人来说，小
菜一叠吧。可用这个app通话质量很差，偶抓破头皮看client的code，也没啥问题。用
sniffer看，原来每个packet间的间隔时大时小，导致很多packet不能按时到达，就过
期作废了。看sender的pattern，非常整齐。那就是linux的问题，偶就开始time自己的
code，同样的非常整齐，没有任何延迟。那是什么原因让linux不马上把偶的data传出
去，而看似毫无规律的乱传？
通过无数个google，bing，终于发现问题的根源。是linux作者在胡乱implement tcp
slow start. Slow start 的spec说tcp session can start with... 阅读全帖 |
|
m**k
发帖数: 290 | 3 99% sure it's nothing to do with "wrong implementation" of TCP slow start.
you shouldn't use TCP at the first hand.
you need to know more about how a packet is transfered from a socket buffer
to driver and then to physical card. There are multiple buffers in this
process. |
|
z**r
发帖数: 17771 | 4 UDP也不能。但是UDP开销小的多，对delay or jitter敏感的应用，无一例外都是用udp
。导致TCP延迟的因素太多了，这里面水很深很深，楼主说不是sender端，就是linux中
转出问题了，这个假设漏洞太多，基本不成立。
最关键的是，楼主的问题解决了吗？还是做了一番研究就放弃了？
这个tcp window不光和congestion window有关，也和advertised window有关，还有
ACK, retransmission等等。楼主要搞定这个问题了，欢迎给大家详细讲讲，俺发大包子 |
|
H*L
发帖数: 124 | 5 Your problem is probably due to bad interaction between tcp delayed ack and
nagle's algorithm. Nagle's algorithm won't send another packet until its
last in flight packet is acked, if the current pkt is too small; on the
other hand , at the other end, tcp will only send every other ack due to the
delayed ack policy
If all your packets are small it's almost guaranteed that you ll ran into
the situation where nagle's algorithm's end is waiting for its previous ack,
and the delayed ack end is not s... 阅读全帖 |
|
f********a
发帖数: 1109 | 6 谢谢，我还有一个问题关于关闭TCP链接。
tcpdump监测到的由client请求关闭TCP链接的3个包如下：
17:29:52.966565 IP (tos 0x10, ttl 64, id 29216, offset 0, flags [DF], proto
cksum 0xb42e (correct), 19:19(0) ack 6593 win 634
2397039718 201985783>
0x0000: 0014 a9ec 05ff 0018 8b56 b16b 0800 4510 .........V.k..E.
0x0010: 0034 7220 4000 4006 210b 0acc a070 40e9 .4r.@.@.!....p@.
0x0020: bb63 ac92 0050 82fc 9779 c470 f679 8011 .c...P...y.p.y..
0x0030: 027a b42e 0000 0101 080a 8edf ec66 0c0a .z...........f..
0x0040: 0ef7 ..
1 |
|
h**********c
发帖数: 4120 | 7 用的openssl biosocket,参考上明确的说是tcp,
另外apache mina介绍codecfactory明确说过tcp会有fragments，但是讲得也不详细。
有什么参考介绍一下吧。 |
|
a****l
发帖数: 8211 | 8 【 以下文字转载自 CS 讨论区 】
发信人: acectl (磨), 信区: CS
标 题: 有谁知道这段tcp通讯到底在干什么事吗？
发信站: BBS 未名空间站 (Fri Apr 12 10:39:23 2013, 美东)
199是client，1是server,应该是199试图连接到1上,然后就开始正常的[PSH,ACK]通讯
的,但是现在似乎总连不上,端口似乎是连上了,但是tcp的连接总是没有建立，整天在忙
着交换这些信息,还总是问arp谁是1，回答了好多遍就是不记住还是问.这到底是怎么会
事?有哪个大牛能看看这些包,说说到底两方面在干什么,为什么总是不能建立连接呢?谢
谢！ |
|
S*A
发帖数: 7142 | 9 这个用如果用普通的Linux，没有 OpenOnLoad 应该是做不出来的。
OpenOnLoad 的内存消耗多少不清楚，没有条件玩。
64G 内存维护 10M 连接在 kernel 的内存不够用。实验表明 2M socket
handle 就要 烧掉 8G 内存。开到10M 估计要 40G。剩下 24G
要保持连接估计是不够的。那个除了 sk_buff, tcp buffer,
还有其他的连接相关的数据结构。你一定要实验的话，可以放开
数据传输不管，测量一下是空的tcp 连接 4G 内存可以上到
多少，这个仅仅是 kernel 部分使用的内存。 所以 64G 应该没有戏。
欢迎实地测试。 |
|
d*******r
发帖数: 3299 | 10 http://www.mitbbs.com/article_t1/Programming/31331437_0_2.html
这种帖子确实让板上很受益呀！
我问个问题，我知道大家做的长连接都是针对 TCP/HTTP 应用的，因为那上面现成的应
用多。
如果自己在UDP上设计协议的话，应该就直接绕过很多问题了吧。比如client的message
/packet 都发到一个 UDP receiver 的话 (比如自己的协议里面有个 virtual sub
port number，用来复用这个 UDP receiver 的 server port number)，server上是不
是一个 UDP socket fd 就够用了，这样就不用折腾 max fd 的限制了。
不知道可不可以直接让 NIC 把 UDP 包扔给 user space app.
user space app 自己做 reliable transmission, flow/congestion control 的话 (
貌似也可以做成一个 user space modified TCP over UDP...)。这样上 C... 阅读全帖 |
|
g*****g
发帖数: 34805 | 11 http://blog.erratasec.com/2013/02/custom-stack-it-goes-to-11.ht
这里不写着吗，custom network stack. You don’t want a full TCP/IP stack
anyway, but a degenerate stack tuned to your application.
This is done first by rewriting the network driver. Instead of a network
driver that hands off packets to the kernel, you change the driver does that
it doesn’t. Instead, you map the packet buffers into user-mode space.
换句话说，要从driver开始写，不做标准的TCP/IP支持。所以部署的软件，不只是OS参
数的问题，换个网卡都不行。在我看来，这种做法，做个DNS, load balancer也许可以
... 阅读全帖 |
|
S*A
发帖数: 7142 | 12 这个用如果用普通的Linux，没有 OpenOnLoad 应该是做不出来的。
OpenOnLoad 的内存消耗多少不清楚，没有条件玩。
64G 内存维护 10M 连接在 kernel 的内存不够用。实验表明 2M socket
handle 就要 烧掉 8G 内存。开到10M 估计要 40G。剩下 24G
要保持连接估计是不够的。那个除了 sk_buff, tcp buffer,
还有其他的连接相关的数据结构。你一定要实验的话，可以放开
数据传输不管，测量一下是空的tcp 连接 4G 内存可以上到
多少，这个仅仅是 kernel 部分使用的内存。 所以 64G 应该没有戏。
欢迎实地测试。 |
|
d*******r
发帖数: 3299 | 13 http://www.mitbbs.com/article_t1/Programming/31331437_0_2.html
这种帖子确实让板上很受益呀！
我问个问题，我知道大家做的长连接都是针对 TCP/HTTP 应用的，因为那上面现成的应
用多。
如果自己在UDP上设计协议的话，应该就直接绕过很多问题了吧。比如client的message
/packet 都发到一个 UDP server port 的话 (比如自己的协议里面有个 virtual sub
port number，用来复用这个 UDP server port)，server上是不是一个 UDP socket fd
就够用了，这样就不用折腾 max fd 的限制了。
不知道可不可以直接让 NIC 把 UDP 包扔给 user space app.
user space app 自己做 reliable transmission, flow/congestion control 的话 (
貌似也可以做成一个 user space modified TCP over UDP...)。这样上 C10M 是不是
也是一种思路?
... 阅读全帖 |
|
g*****g
发帖数: 34805 | 14 http://blog.erratasec.com/2013/02/custom-stack-it-goes-to-11.ht
这里不写着吗，custom network stack. You don’t want a full TCP/IP stack
anyway, but a degenerate stack tuned to your application.
This is done first by rewriting the network driver. Instead of a network
driver that hands off packets to the kernel, you change the driver does that
it doesn’t. Instead, you map the packet buffers into user-mode space.
换句话说，要从driver开始写，不做标准的TCP/IP支持。所以部署的软件，不只是OS参
数的问题，换个网卡都不行。在我看来，这种做法，做个DNS, load balancer也许可以
... 阅读全帖 |
|
g*****g
发帖数: 34805 | 15 你就别撑了， Robert提了几点。一个是要从 driver开始写，一个是根据应用不同对
network stack 选择性实现，或者部分支持，以达最简目的。还有一个就是没有任何开
源可靠的user space TCP/IP实现，所以你只能自己写。
nginx支持 http, 因为 http 本来就是个应用层协议，也不会换个网卡就不能用。撑也
没有这么撑的，你不服从驱动到 TCP实现了再来。我不说了，你这思路就是错了，一个
堆机器就能解决的问题，要等别人的研究成果。要是研究不出来，你就不做了？ |
|
g*****g
发帖数: 34805 | 16 做人不要那么不要脸。你要提robert，又要选择性无视。Robert明明说了没有可靠的
user modde tcp/ip可用。也没听说哪个相似server产品用了OpenOnLoad，你还有脸谈
阅读能
力。
Your biggest problem is getting a user-mode TCP/IP stack. There are lots of
these stacks around as university research projects. I don’t know of any
open-source user-mode stack that is reliable. There is a closed-source stack
called “6windgate” which is used in a lot of appliances.
几个外行，成天意淫10M单机，实际上连一万单机都没做过。还是那句话，有种的跟我
说，没做过1万server并发的死全家好了。实践检验真理唯一标准，不是拿helloworld
来检验whatsapp。我产品里做过10M 用户... 阅读全帖 |
|
S*A
发帖数: 7142 | 17 这个练习1 已经发现了，C10M 没有强壮的内存支持是
没戏的。单单是 kernel 部分就已经消耗很多内存了。
所以我们把目标调整一下，1M per 4G RAM。
这样 64G 内存就有可能实现 10M。
练习2 就是看看，我们如果保留 1M/4G 的空TCP
连接，可不可以。完全不往 TCP 里面发东西。就是
建立连接而已。这样也不存在 epoll 问题。
和实验1一样，我会发些拍脑瓜想出来的简单代码。
你直接用这个代码冲刺 1M/4G 会碰到些实际问题。
有兴趣的同学跟着做一下实验，看看有没有办法解
决这些问题。
BTW，我是实验出了 1M/4G (服务器方），所以是
有可能的。建立1M 连接还花了不少时间。
服务器方代码。端口是80， 大家可以自己改。
include
#include
#include
#include
#include
#include
#include
#include 阅读全帖 |
|
S*A
发帖数: 7142 | 18 回到正题上，用 4G 内存的笔记本保持 1M 个空的 TCP 连接
我已经实验出来了。所以这一步定下的目标是可以是实现的，
大家不用过于担心 4G 不够用的问题，至少这一步不用。
还是需要在客户端改用指定的 IP 地址才能避免同一个 IP 有
65K 个端口的限制。现在我还没有看到有其他同学贴这个代码
出来。这样吧，我再放 10 个包子，给第一个贴用多个 IP 连
接的。就是简单的 socket 编程啊。
然后我再追加一个非常简单的要求，原来程序里面得到的连接
的 handle 是直接扔掉的。现在要求把得到的 handle 放到一个
大数组里面，1M TCP 就是 4M 空间，很小。然后这把柄的数
组就是下一步练习 3 epoll 要用到的。
大家加油啊。 |
|
S*A
发帖数: 7142 | 19 这个练习1 已经发现了，C10M 没有强壮的内存支持是
没戏的。单单是 kernel 部分就已经消耗很多内存了。
所以我们把目标调整一下，1M per 4G RAM。
这样 64G 内存就有可能实现 10M。
练习2 就是看看，我们如果保留 1M/4G 的空TCP
连接，可不可以。完全不往 TCP 里面发东西。就是
建立连接而已。这样也不存在 epoll 问题。
和实验1一样，我会发些拍脑瓜想出来的简单代码。
你直接用这个代码冲刺 1M/4G 会碰到些实际问题。
有兴趣的同学跟着做一下实验，看看有没有办法解
决这些问题。
BTW，我是实验出了 1M/4G (服务器方），所以是
有可能的。建立1M 连接还花了不少时间。
服务器方代码。端口是80， 大家可以自己改。
include
#include
#include
#include
#include
#include
#include
#include 阅读全帖 |
|
S*A
发帖数: 7142 | 20 回到正题上，用 4G 内存的笔记本保持 1M 个空的 TCP 连接
我已经实验出来了。所以这一步定下的目标是可以是实现的，
大家不用过于担心 4G 不够用的问题，至少这一步不用。
还是需要在客户端改用指定的 IP 地址才能避免同一个 IP 有
65K 个端口的限制。现在我还没有看到有其他同学贴这个代码
出来。这样吧，我再放 10 个包子，给第一个贴用多个 IP 连
接的。就是简单的 socket 编程啊。
然后我再追加一个非常简单的要求，原来程序里面得到的连接
的 handle 是直接扔掉的。现在要求把得到的 handle 放到一个
大数组里面，1M TCP 就是 4M 空间，很小。然后这把柄的数
组就是下一步练习 3 epoll 要用到的。
大家加油啊。 |
|
|
c*********e
发帖数: 16335 | 22 比如nodejs官方网站上的一个例子：注意，是tcp server,不是http server:
Here is an example of a simple TCP server which listens on port 1337 and
echoes whatever you send it:
var net = require('net');
var server = net.createServer(function (socket) {
socket.write('Echo serverrn');
socket.pipe(socket);
});
server.listen(1337, '127.0.0.1');
－－－－－＝－－－－－－－－－－
用的就是socket,而且貌似和 |
|
a9
发帖数: 21638 | 23 server push也是得用tcp或udp连接的啊。
这跟你哪种手机有关，iphone你根本就维持不了连接。
server push,还是tcp ? |
|
b***i
发帖数: 3043 | 24 我用C++11和ASIO（从boost那里剥离出来的）来写TCP/IP。上位机向嵌入式发送JSON。
那么我用asio::async_read来读入所有的，结果handle_read没有被通知。有人说是TCP
是一个流，中间没有分割符。
现在我理解了，为什么软件组放弃了压缩传送JSON的方案，因为还要提前发送长度等信
息。
那么，我是不是可以用carriage return或者特殊字符来作为JSON的终止标记？就是用
asio::aync_read_until(..., 'n',...)来读入知道收到回车为止？大家是这么做的吗？
我不想用json{}的匹配来通知handle_read, 因为asio没有智能到和jsoncpp一起来判断
什么时候通知handle_read。我想要简单的方法来收到一个整个JSON，然后在解析。 |
|
p***o
发帖数: 1252 | 25 TCP是一个流, 要么先加长度要么后加分隔符。
TCP
吗？ |
|
|
s*******m
发帖数: 58 | 27 如果你的发送接收逻辑比较简单，没有必要用ASIO，直接用socket
如果是一次性发送的话，你最好不要用裸的TCP。
ASIO支持HTTP，可以用它。
或者用thrift over TCP, 把你的JSON作为一个string，或者直接用thrift
serialization, 它也支持serialization to JSON,但没有必要 |
|
j******a
发帖数: 100 | 28 1M 个 TCP 开关没有机器做得到,协议就是这样了
长连接 1M 个 tcp req/response，轻轻松松
兰州信口开河，挺会忽悠，1ms+ 系统调用时间随口就来
其实随手ping一台就知道他在扯淡
64 bytes from 172.31.32.255: icmp_seq=1 ttl=64 time=0.016 ms
前面的哥们说很对
/dev/null read是空的，/dev/zero多了地址check，中途要reshed一次，所以会慢，而
且结果不稳定 |
|
a****1
发帖数: 20 | 29 帖子太多， 不是很清楚， 请魏老师或者其他明白人说明一下。
每个请求是用单独的 tcp connection 吗？还是可以把很多个请求batch 在一个 tcp
request 里？
如果是前者， 那是很牛。 我以前测过， 无论是 apache, 还是 nodejs, vertx, 每秒
处理并发连接， 即便是很简单的处理， 离 1M 差很远。
如果是后者， 那就没什么挑战性了。 |
|
s****l
发帖数: 600 | 30 有一个TCP server比较old school，收一个request，计算返回然后close tcp
connection。
现在要做benchmark，客户端开10个线程，发1百万个请求来测试Req/Sec。
大概70万就connection timeout了，server side一大堆的TIME_WAIT的connection。
奇怪的是每次connect timeout客户端ssh竟然断掉了。
benchmark只是拿2个VM来做，所以实际上还有空间。
同样的实验，用udp可以完成。 |
|
l******0
发帖数: 313 | 31 【 以下文字转载自 EmergingNetworking 讨论区 】
发信人: love1010 (亲爱的~), 信区: EmergingNetworking
标 题: 请教：哪里有C语言写的TCP/IP stack and web server？
发信站: BBS 未名空间站 (Fri May 15 23:54:43 2009)
要求是不需要Operating system就可以运行。TCP/IP只和Ethernet port通信，Web
server也只和Ethernet port通信~ 不需要underlying 的OS~
多谢~ |
|
m****f
发帖数: 32 | 32 I am reading a paper
http://www.cs.unc.edu/Research/dirt/abstracts/SIGCOMM-2000-abs.html . I don't
understand the concept of TCP throughput as appears in the following sentence
in that article:
"Although the performace of RED and other early congestion notification
mechanisms continue to be the subject of much study, the evaluation metrics
have largely been network-centric measures such as network link utilization or
aggregate TCP throughput."
Can you guruish people kindly educate me pls?
Thank |
|
g******r
发帖数: 55 | 33 I want to abruptly kill a TCP session without sending the FIN?
I found two methods:
1) I may disable the LAN interface. But I can't connect the internet with
this
method.
2) Use "netstat -ano" to get the PID, and use "taskkill" to kill the process
.
But by killing the process, the FIN is still being sent.
Is there other method to abruptly kill a specific TCP session?
Thanks, |
|
z*****n
发帖数: 7639 | 34 In your case, if you send 10 packets, the receiving
TCP should send ACK for each one individually.
In case if all of these 10 packets arrive at destination
as one notification (IP layer may accumulate the
packets and send them up in one time), then ACK10 is
send back.
In case seq:5 is missing, the receiving TCP will send
back ACK5 for sure. And the sender will retransmit
all the rest packets in the window.
Yes it is very inefficient in a multi-hop wireless
network. There are a huge number of dis |
|
s********k
发帖数: 6180 | 35 非常感谢，一个小小的问题，现在TCP都是采用cumulative acknowledgment scheme吧
。如果在我这种window size为10的情况下，TCP ACK不应该是individually？即便ＩＰ
层对这些ｐａｃｋｅｔｓ是分别传送的 |
|
z*****n
发帖数: 7639 | 36 It depends on how these packets are re-assembled by
the IP layer.
If the TCP layer at the receiver receives incoming
packet (from its own IP layer) one by one, then
individual ACKs are sent back. If IP layer buffers
several packets and sends to TCP together, then
the last one is ACKed. Actually I am not sure the
mechanism of IP layer re-assembly function. This
question is also open to me... |
|
s********k
发帖数: 6180 | 37 感觉应该是TCP，不是很确定。另外比如文件传输，这个应该是标准的TCP应用，但是比
如我用QQ传输比用MSN传输快很多，难道是两者做了不同优化，还是什么其他原因？ |
|
t**o
发帖数: 1030 | 38 是OS范围的。
我的意思是在网络冗塞在可以承受的范围内，如果到了冗塞严重的情况时，有可能TCP
跟UDP的效果是一样的。多线程当然无法解决这个问题。但就流媒体传输质量来说，当
然是TCP啊。
话说回来，本来流媒体就是针对网络情况比较好的条件下的，网络超时严重的谁还去玩
这些啊 |
|
g******r
发帖数: 55 | 39 I want to abruptly kill a TCP session without sending the FIN?
I found two methods:
1) I may disable the LAN interface. But I can't connect the internet with
this
method.
2) Use "netstat -ano" to get the PID, and use "taskkill" to kill the process
.
But by killing the process, the FIN is still being sent.
Is there other method to abruptly kill a specific TCP session?
Thanks, |
|
w*******y
发帖数: 60932 | 40 I was wondering around Home Depot and noticed that they had reinstated the
TCP Contractor pack of 12 for $3.47. They were originally $15.47 per pack
but marked down a lot less on the shelf.
I have enough from last time (got 6 boxes) but figured that someone could
use the deal.
I used 10% Off Lowe's coupon from the Post Office and they cost $3.12 before
tax.
I can't get the pictures off my phone but the UPC is:
7 62148 10540 4
The manufacturer is TCP and the item # looks like it is 2700K
This ma... 阅读全帖 |
|
w*******y
发帖数: 60932 | 41 Cheaper Than Dirt has the Taurus 732 TCP Semi Automatic Handgun .32 ACP 3.3"
Barrel 6 Rounds Black Polymer Frame Stainless Steel Finish for $180.53 plus
approx $10 in shipping. No tax unless in Texas.
Excellent concealed Handgun, Identical to the 738 TCP other than ammo size.
Link to Website::
http://www.cheaperthandirt.com/2TI732039-1.html
|
|
c*******a
发帖数: 1879 | 42 【 以下文字转载自 Programming 讨论区 】
发信人: centralla (central LA), 信区: Programming
标 题: Re: 这个改进TCP的研究看起来很厉害
发信站: BBS 未名空间站 (Fri Aug 23 14:14:02 2019, 美东)
这种都是傻逼赚眼球的纸上谈兵
按照自己的模型框框在自己嗨
到实际中会死的一塌糊涂
垃圾文章害死人 |
|
c*****e
发帖数: 215 | 43 丢失的电子货币很难全方位追踪，那是因为现在广泛使用的TCP/IP 协议本身存在安
全漏洞，本身无法完全修补。如果一定要解决这个网络协议带来的安全隐患，唯一
的办法是使用其他网络传输协议，但是这牵涉全球服务器的UPDATE，花费太大，没
有多少国家的政府愿意批准采纳。
所以从执政者这个角度来讲，还是不应该鼓励这种虚拟货币的发展，因为毕竟是纯
粹的金融衍生品，不是实体经济，不能从根本上带来一个国家的经济发展。 |
|
m***i
发帖数: 980 | 44 几个人的小公司，在Irvine附近。人际关系简单，除了我之外全是老美。工作时间比较
自由。工资是OC的平均水平。
要求熟悉C，RTOS，BSP,熟悉TCP/IP内部工作原理，（不是只使用socket接口)
请通过站内信箱发联系方式。 |
|
s********a
发帖数: 1447 | 45 about VPN. tell me about the architecture of TCP/IP protocol which used
in client/server situation
这个怎么回答？ |
|
c*******n
发帖数: 112 | 46 In this case, you need to know how VRF is operated in a network, e.g, BGP,
RT, RD. I guess this is not very easy to describe in a interview. I do not
think this is a good interview question.
Since the question is related to TCP/IP, I assume it is L3VPN, not L2VPN. |
|
j*****l
发帖数: 1624 | 47 本人非网络专业，几年grad school读下来由于不是这个area的，tcp/ip已经忘记得差
不多了。为了保险起见，还是想申请google,向来只看到版上关于算法数据结构C++的面
经，请问有没有谁被问过关于网络的问题。是不是需要自己做一个小项目来说明自己的
能力呢。
万分感谢。 |
|
j*****l
发帖数: 1624 | 48 谢谢这位大大。
主要是看到要求里面有一条说需要知道tcp/ip的。 |
|
k***t
发帖数: 276 | 49 可能本来是想说，申google前，为保险起见想确认一下google到底问不问tcp/ip。 |
|
