Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 8 years ago.
Improve this question
I am trying to understand TCP congestion avoidance mechanism, but I don't understand one thing:
TCP congestion avoidance is per flow or per link?
In other words: there are 2 routers A and B
A is sending B two TCP flows - when one TCP flow detects congestion, does it decrease window size in the other flow as well?
of course if this happens, the other flow will detect congestion in some time, but does the second flow "waits" until it detects congestion on its own? that would be quite uneffective...
thanks a lot
It decreases the window size for the current connection. Each connection's RTT and windows are maintained independently.
Routers operate on layer 3 (IP) and are not aware of layer 4 (TCP), because of this, routers do not take any part in TCP congestion avoidance mechanism. This mechanism is fully implemented by TCP endpoints. It is triggered by routers dropping IP packets, but (classic) routers are not aware what higher level protocol IP packets carry.
The fact that one flow does not affect the other is quite desirable from the security perspective. With NAT you can have many hosts sharing the same IP address. From the outside world all these hosts look as a single machine. So, if some server reduced throughput of all TCP connections coming from a single IP address in response to packets dropped within one of those connections that would open a door to quite nasty DoS attacks.
Another issue is that some routers may be configured to drop packets based on IP ToS field. For example, latency sensitive SSH traffic may set different ToS than bulk FTP download. If router is configured to take into account ToS field, it may drop packets belonging to FTP connection, which should trigger congestion avoidance, but is should not affect packets belonging to SSH connection, which may be handled with higher priority.
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 7 years ago.
Improve this question
Before a browser can request for a webpage, A TCP connection is required to be established. What is the necessity of 3 way handshake in interacting with a server computer? why can't we simply send a web request and wait for the response?
Shouldn't the resolution of IP address be enough for this purpose?
Basically, I need to know the reason for establishing TCP connection.
thanks in advance
You are using a device named A and server is named B
Host A sends a TCP SYNchronize packet to Host B
Host B receives A's SYN
Host B sends a SYNchronize-ACKnowledgement
Host A receives B's SYN-ACK
Host A sends ACKnowledge
Host B receives ACK.
TCP socket connection is ESTABLISHED.
See more at: http://www.inetdaemon.com/tutorials/internet/tcp/3-way_handshake.shtml#sthash.F2f4b8Xn.dpuf
Because you need a TCP connection to send HTTP over, and TCP has a 3-way handshake.
Basically, I need to know the reason for establishing TCP connection.
Because HTTP runs over TCP. It doesn't exist in a vacuum.
TCP provides ordering, automatic retransmission, and congestion control. I'd say these are the obvious reasons why the design adopted TCP.
In contrast, e.g. UDP is fast. There is no handshaking. But UDP packets are not ordered, also packets can get lost (no automatic retransmission), and there is no congestion control.
You can try implementing your data transferring for things like HTML in UDP. It's not easy, you still need to reinvent ordering and retransmission for reliable lossless delivery.
If you don't care about lossy or a bit out-of-order transferring then you probably don't need TCP. (e.g. real time video)
--
On the other hand, avoid TCP to get better performance is not necessarily a bad idea. Read about QUIC. (It also has features like loss recovery and congestion control, you should not expect it to be extremely lightweight.)
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 7 years ago.
Improve this question
I want to establish an UDP communication between two peers, say Alice and Bob. Alice is behind a port restricted cone NAT (so that the same internal port gets mapped to the same external port even if the destination is changed), while Bob is behind a symmetric NAT (which means that the external port will change every time a new destination is chosen regardless of the internal port, thus making the external port unpredictable). I have a server in between and I want to make an UDP hole punch.
I implemented the following strategy:
Bob opens a large number of ports and from all of them sends a packet to Alice's external port (he gets to know if through the server).
Alice sends packets to Bob's NAT at random ports until the connection is established.
Having two NATs of those types at hand, I did some experiments. Bob opens 32 ports, and Alice sends 64 packets every 0.1 seconds. The connection is usually established within 1 or 2 seconds, which is more than suitable for my needs.
However, I was wondering if I could get in trouble with some strict NAT routers or firewalls. On example, could it happen that a router won't allow an internal peer to open 32 ports? Or (and this sounds somehow more likely) could it happen that a router that sees a lot of packets incoming on random ports that get dropped will blacklist the ip and drop all its packets for some time? I read that sometimes this could happen in case of a DoS attack but my packet rate is something like 4 to 6 orders of magnitude lighter than a DoS attack.
I am asking about reasonable network configuration: I am pretty sure that in principle it is possible to setup a firewall to behave in that way. I will be targeting mainly users that lie behind standard home connections, so my main target is common internet providers that use NATs.
It's an interesting question.
First of all, I'm not sure anyone has the exact answer you're looking for. Different networks use different equipment and different configuration. Two ISPs can use ten different vendors for their routers, firewalls, NATs, intrusion detection equipment, DPI equipment etc; not to mention the number of possible configurations all of this equipment has.
And while commercial and corporate networks are bad enough, home networks are even worse. Here there are even more vendors selling modems, NAT boxes, and various software that affects network connectivity (such as firewalls and anti-viruses). All of which is in the hands of users who aren't technically savvy that leave it with the default settings, or worse.
Moreover, in both home and commercial networks there might be several layers of NAT. I know of a company that has a NAT for each lab (to isolate it from other labs and the R&D network). Each lab is then connected to the R&D NAT (to isolate it from other departments), which in turn is connected to the company-wide NAT, which, by the way, is also heavily firewalled. Add to that a possible ISP-level (carrier grade) NAT, and you're looking at up to 4 layers of NAT. Hopefully this is an extreme example, but two layers of NAT are quite common nowadays with home NAT and carrier grade NAT.
Given that, how likely it is for a random network to consider this behavior suspicious and limit it? Frankly, I don't know for sure and I don't think anyone else does with a high degree of certainty.
Despite that, my educated guess is that sane default configurations of communication equipment (NATs, routers, etc) should not block such behavior. After all, many applications open several ports; not to mention the fact that the NAT has no way of knowing that the IP sending this traffic isn't itself a NAT device with dozens of computers behind it - each of them with several open ports.
I also guess that simple firewalls should be fine with it as long as UDP itself isn't blocked, and the usage of the various ports is allowed. Firewalls that attempt to block port-scanning, and anti-DDoS equipment, however, might pose a problem as this traffic might seem suspicious to it, so it might depend on the configuration/implementation details of such equipment and software. So unfortunately, the only way to tell how your strategy will behave in the real world it to try it out on a variety of different networks.
Second, I'd like to say a few words about your hole punching strategy. If both Alice and Bob have a shared server, and Alice is behind a cone NAT, I don't see the point in your strategy. A cone NAT is the simplest NAT to overcome. If you want Alice to be able to connect to Bob (which is tricky since he's behind a symmetric NAT), all you really have to do is to get Bob to connect to Alice upon Alice's request.
To do that, both Alice and Bob should always have a long-lasting TCP or UDP connection to the server. The connection shouldn't carry any data for the most part, and should be just kept alive once in a while.
When Alice wants to connect to Bob, it just opens a port (say port X), and connects from that port to the server. The server sees Alice's external port that corresponds to port X - say port Y. At this point, Alice informs the server that she would like Bob to connect to her. Since Bob is connected to the same server, the server informs Bob that it should connect to Alice at at port Y. This should establish a connection between them without the need for any guessing.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 8 years ago.
Improve this question
Transmission Control Protocol and Internet Protocol are two different protocols.
then why they are always mentioned together.
The official name for TCP/IP is Internet Protocol Suite. TCP/IP is a shorthand used by its authors to refer to this new iteration of a standard based on a previous protocol simply called TCP (for Transmission Control Program), so one may infer that the new acronym was meant to differentiate from the latter.
Quoting the Wikipedia entry:
In May 1974 the Institute of Electrical and Electronic Engineers
(IEEE) published a paper titled "A Protocol for Packet Network
Intercommunication." The paper's authors, Vint Cerf and Bob Kahn,
described an internetworking protocol for sharing resources using
packet-switching among the nodes. A central control component of this
model was the Transmission Control Program that incorporated both
connection-oriented links and datagram services between hosts. The
monolithic Transmission Control Program was later divided into a
modular architecture consisting of the Transmission Control Protocol
at the connection-oriented layer and the Internet Protocol at the
internetworking (datagram) layer. The model became known informally as
TCP/IP, although formally it was henceforth called the Internet
Protocol Suite.
Source: http://en.wikipedia.org/wiki/Transmission_Control_Protocol#Historical_origin
They are the protocols used by the Internet Protocol Suite and are always mentioned together because they both are necessary to transmit data over the internet.
From wikipedia: "TCP provides reliable, ordered and error-checked delivery of a stream of octets between programs running on computers connected to a local area network, intranet or the public Internet." and "IP,[...] has the task of delivering packets from the source host to the destination host solely based on the IP addresses in the packet headers."
When you need to send a message from one computer to another the TCP is responsible to break this message in smaller packages and leave the rest of work to IP, that takes care of deliver these smaller groups of data to the correct destination. In the other side, when the other computer receives the packages, TCP assembles them to get the original message.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
I would like to create a new protocol, i.e having features of TCP and UDP. can you tell me what are tips and techniques are required if it is possible.
Thanks in advance
TCP gives you three features that UDP does not: (a) estimating sending rate, (b) retransmission, and (c) flow-control. In doing so, the tradefoff is that TCP becomes slower compared to UDP. So, if your application is delay sensitive, which is typically true for audio/video applications, then you need to start with UDP and keep whichever of the above three you want. Typically, UDP applications might add forward-error-correction or application layer packet-book-keeping to ensure retransmission.
There is yet another advantage that UDP offers which TCP does not: if you have an application that might use mulitcast. For such cases, UDP would be the right chioce since UDP can handle point to multipoint. Using TCP for multicast applications would be hard since now the sender would have to keep track of retransmissions/sending rate for multiple receivers.
So, in summary, UDP will offer you two features that TCP cannot: lower-delay and ability to do multicast. So, this way, we can actually reduce the scope of the question and ask what are the features of TCP that one would like to add to UDP since there is no way, one can add features of UDP to TCP.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 2 years ago.
Improve this question
I know that when a HTTP request is made, packets are sent from a seemingly-random high-numbered port (e.g. 4575) on the client to port 80 on the server. Then the server sends the reply to the same high-numbered port, the router knows to route that to the client computer, and all is complete.
My question is: How is the return port (4575 in this example) determined? Is it random? If so, within what range? Are there any constraints on it? What happens, for example, if two computers in a LAN send HTTP requests with the same source port to the same website? How does the router know which one to route to which computer? Or maybe this situation is rare enough that no-one bothered to defend against it?
The NAT is going to decide/determine the outbound port for a NATed connection/session, via it's own internal means. Meaning, it will vary according to the implementation of the NAT. This means any responses back will come back to that same outbound port.
As for your question:
What happens, for example, if two computers in a LAN send HTTP
requests with the same source port to the same website?
It will assign different outbound ports for each. Thus, it can distinguish between the two in responses it receives. A NATs would create/maintain a mapping of translated ports, creating new outbound port numbers for new sessions. So even if if there were two different "internal" sessions, from two different machines, on the same port number, it would map to two different port numbers on the outgoing side. Thus, when packets came back in on the respective ports, it would know how to translate them back to the correct address/port on the inside LAN.
Diagram:
It depends on the NAT and on the protocol. For instance I'm writing this message behind a full cone NAT and this particular NAT is configured (potentially hard-wired) to always map an UDP private transport address UDP X:x to the public transport address UDP Y:x. It's quite easy to shed some light on this case with with a STUN server (google has some free stun servers), a cheap NAT, 2 laptops, wire shark and a really really light STUN client which uses a hard coded port like 777. Only the first call will get through and it will be mapped on the original port, the second one will be blocked.
NAT's are a hack, some of them are so bad that they actually override on return the public transport address not only in the header but even in the transported data which is kinda crazy.
ICE protocols has to xor the public address to bypass this issue.