I have a question about packetloss in streaming (UDP protocoll) and I have packetloss with every Cloud-Gaming streaming provider and the only workaround is a VPN with TCP as protocoll.
The problem is that here in Germany the peering is totally bad so UDP packets on the way have problems to be transmitted properly.
VPN with TCP as a protocol creates help here by packing the UDP packets in a TCP frame (I think) and then routing them.
As soon as I switch the VPN off or back to UDP I have packetloss again, TCP is the only way I can get rid of the streaming problem, unfortunately one can't select TCP as protocoll in the settings of the cloud providers, so I have to rely on VPN with TCP.
Sadly the ping and the response time increases a lot, because the route is extended and therefore overhead is created.
Are there other ways to force streaming over TCP? Maybe via Windows GPO/Registry or router settings?
I don't want to rely on VPNs, as they cost money and improve the experience in general, but don't solve the problem overall.
Related
Why was UDP used as the standard protocol in NFS systems up to version 3 and TCP in version 4? Unfortunately, I have not yet found anything about the motives that led to this.
The Red Hat NFS documentation provides some insight about why UDP was preferred:
When using NFSv2 or NFSv3 with UDP, the stateless UDP connection under normal conditions has less Protocol overhead than TCP which can translate into better performance on very clean, non-congested networks.
...and why the move to allow and eventually require TCP was made:
However, because UDP is stateless, if the server goes down unexpectedly, UDP clients continue to saturate the network with requests for the server. For this reason, TCP is the preferred protocol when connecting to an NFS server.
The current RFC also notes that TCP facilitates transport security without needing to tunnel:
Historically, NFSv2 and NFSv3 servers have resided on port 2049. The registered port 2049 [RFC3232] for the NFS protocol SHOULD be the default configuration. Using the registered port for NFS services means the NFS client will not need to use the RPC binding protocols as described in [RFC1833]; this will allow NFS to transit firewalls.
Why TCP specifically? Actually, the RFC says SCTP is also acceptable (though TCP support is mandatory):
Where an NFSv4 implementation supports operation over the IP network protocol, the supported transport layer between NFS and IP MUST be an IETF standardized transport protocol that is specified to avoid network congestion; such transports include TCP and the Stream Control Transmission Protocol (SCTP). To enhance the possibilities for interoperability, an NFSv4 implementation MUST support operation over the TCP transport protocol.
Finally, addressing performance, the original reason UDP was chosen, the RFC says:
If TCP is used as the transport, the client and server SHOULD use persistent connections. This will prevent the weakening of TCP's congestion control via short-lived connections and will improve performance for the Wide Area Network (WAN) environment by eliminating the need for SYN handshakes.
Ultimately, only the engineers at Sun Microsystems (as the creators of NFS) know the exact reasons UDP was chosen and only the IETF working group for NFS (as the maintainers) know why the switch to TCP was made.
I am debugging some code which is using UDP communications.
My CLIENT is behind a NAT and a Firewall.
My Server is an AWS machine on which I opened said UDP ports.
However, part of this protocol involves the server answering my client. Which I expected not to work (NAT & Firewall). To my surprise, my client is recieving packets from the server!
How is this possible? I mean, TCP (over UDP) has a concept of a connection, so I guess that the NATs and routers can associate an incomming UDP packet as a reply to an egress connection. But how (and why) does this work for a pure UDP protocol? Would my NAT/Firewall let in random UDP into my client machine?
How is this possible?
That's how NAT works. You wrote that the server is answering you client. That means that the client initiated the conversation. It doesn't matter that you're using UDP and not TCP. The NAT device still creates an appropriate mapping to let answers trough. Otherwise all UDP would have been broken behind NAT.
I mean, TCP (over UDP) has a concept of a connection, so I guess that
the NATs and routers can associate an incomming UDP packet as a reply
to an egress connection. But how (and why) does this work for a pure
UDP protocol?
The fact that UDP isn't connection-oriented is irrelevant. Sure, TCP has the concept of sessions, but both have port numbers and that's really all the NAT needs.
Would my NAT/Firewall let in random UDP into my client machine?
It's not "some random UDP". It's a UDP segment from the same IP and port number that the client sent something to.
I am using wireshark, and for an exercise we need to capture a UDP packet with wireshark by visiting any website, and then analyze the information within that packet.
I have tried numerous times and all websites appear to send packets with TCP protocol. I have looked at Wireshark documentation, as well as looked online and am stumped.
What am I doing wrong, and how can I get a UDP packet by visiting a website?
Thats the main question. A side question is: how do I filter the captured packets to only those packets referring to requests and responses from websites over the network? Currently there appear to be a bunch of low-level captured packets that I need to scroll through.
Thanks in advance!
Because websockets/HTTP is over TCP.
And in Wireshark,if you are intending to see packets corresponding to a particular client/server, click on the packet and do "Follow TCP/UDP stream"
You will never see a UDP packet in a WEB connection. Never never never. The Web's connection is in HTTP protocol and HTTP is encapsulated in TCP.
If you need see UDP packets en wireshark you can generate UDP sockets from your host. You can:
Make a connection with a TFTP server.
Renew your IP you will see the DHCP protocol.
You search, what protocols are encapsulated in UDP and use it.
Make a program with UDP sokects.
Can I disable the ACK mechanism for TCP connections. In my country the DPI is activated for VoIP which blocks the remote end IP. (weather used with openvpn or IPsec or etc). However they are not monitoring TCP. the VoIP operates at TCP but the quality is very bad due to ACK function. I did try some DELACK but did not paid me off much. Could it be possible that I can disable the ACK in TCP protocol using some patch or some thing so I can operate VoIP with it. My servers are Linux CentOS based.
No.
TCP without ACK isn't TCP.
If you were to hack the TCP stack somehow and prevent ACKs being sent then all kinds of things would stop working. You would need to adjust your version of TCP to the point where it simply wasn't TCP anymore. You would then need it running at both ends of the connection.
If a client inside firewall connects to a public server through TCP, once the connection is formed, the firewall allows two-way communication. This is what we normally see in our daily usage. My question is: is this also true for UDP?
Since UDP does not have connect, I will modify the question a little bit...
Suppose the client inside firewall sends a UDP packet to a public server, can the server respond back through firewall using the source address and port of incoming packet?
Yes this is called NAT traversal (or UDP punch through) and works in a similar way to TCP - the stateful NAT device is aware you recently sent a UDP packet from a certain end point internally to a certain end point outside and for a period will accept UDP packets from the same outside endpoint and forward them to the same internal end point.
I always prefer the IETF docs than the plethora of conflicting information out there (including on this site):
https://www.rfc-editor.org/rfc/rfc5128
UPDATE: There are other techniques to "UDP hole punching" such as UPnP's Internet Gateway Protocol and PCP. Each has their advantages and disadvantages and I am afraid there is no one solution works on all NATs!