Http UDP or TCP

http://1024monkeys.wordpress.com/2014/04/01/game-servers-udp-vs-tcp/

When writing online games, the question of whether to use UDP or TCP will have to be faced sooner or later.

In general, you will hear people say, "Unless you're writing an action game, you're going to use TCP," or "You can use TCP in MMO games, because World of Warcraft tcp! ”

Unfortunately, these views do not reflect the complexity of the problem.

Background

First, let me explain that I used to do network programming primarily with TCP. I have been writing servers for a popular online card game for several years, and at peak times our servers were able to withstand between 4000 and 10,000 connections (multiple server processes running on the same physical machine) were fine. In my opinion, TCP is a safe and common choice.

However, our newest project is using the UDP protocol, and our project cannot work in any way under TCP. In fact, the project started with TCP, but later found that we were unable to use TCP to reach the number of connections we needed, we were only able to switch to UDP.

How does TCP behave in use?

In principle, the advantages of TCP are:

• Simple and direct long connection
• Reliable Transmission of information
• There is no limit to the size of the packet

Anyone who has dealings with TCP knows that to achieve a stable TCP network connection, you need to deal with a variety of hidden pits, such as wire break detection, slow client response blocking packets, various Dos attacks on open connections, blocking and nonblocking IO models, and so on.

In addition to the problems listed above, a good TCP module does not really do well with coding implementations.

However, the worst feature of TCP is its control over blocking. In general, TCP assumes that packet loss is due to insufficient network bandwidth, so when this happens, TCP reduces the rate of the packets.

In 3G or WiFi, a packet is lost, you want to immediately re-send the packet, but TCP blocking mechanism is completely in the opposite way to deal with!

And there is no way to circumvent this mechanism, as this is the basis for TCP protocol construction. This is why ping values can rise to more than 1000 milliseconds in 3G or WiFi environments.

Why not use UDP

UDP is both simple and difficult relative to TCP.

For example, UDP is based on packet construction, which means that in some ways you need to completely subvert the idea under TCP. UDP uses only one socket for communication, unlike TCP, which needs to establish a socket connection for each client. These are very good places for UDP.

However, most of the things you need are just some connection concepts, some basic package functions, and so-called connection reliability. Unfortunately, none of these features can be easily provided to you, and you get it for free using TCP.

This is the reason why people often recommend TCP. When using TCP, you can not consider these problems until you need to synchronize the number of connections to reach more than 500.

So, yes, UDP doesn't provide all the solutions, but as you can see, this is where UDP works. In a sense, TCP is like the difference between hibernate and handwritten SQL for UDP.

Where TCP failed to use

People often advise you to use TCP, such as "TCP is as fast as UDP" or "game X is so successful with TCP, so TCP is of course preferred", however, they do not understand why TCP is valid in that particular game, why does UDP not send packets in sequence?

So why does World of Warcraft use TCP? First we need to explain the problem. The question is, "Why does World of Warcraft have a delay of more than 1000 milliseconds to run?" "This is the nature of TCP, and in the event of packet loss, there is a huge delay because TCP first detects which packets have been lost and then re-sends all the lost packets until they are received."

Reliable UDP is also delayed, but because it is a communication protocol established on the basis of UDP, there are many ways to reduce latency, unlike TCP, where everything depends on the TCP protocol itself and cannot be changed.

In this regard, some people are going to start mentioning the Nagle algorithm, which is actually the first thing you need to disable when implementing any of the latency-sensitive TCP models.

So how does World of Warcraft and some other games deal with latency issues?

The method is also very simple, they can hide the impact of the delay.

In World of Warcraft, players and players are not able to collide: because such collisions cannot be handled by some predictions, but the collision between the player and the environment can be handled by prediction, so there is no problem using TCP here.

Let's take a look at the Battle of World of Warcraft and find out that the player's attack instructions are sent to the server, such as "attack_entity (entity_id)" or "Cast_spell" (entity_id, spell_id )", in other words, the aim operation is independent. In this way, some similar attack actions and release skill effects can be executed without receiving confirmation from the server, such as the effect of freezing skills can be done on the client before the server does not return data.

The client directly starts the calculation without waiting for the service-side acknowledgment to be a typical hidden latency technique.

A few years ago, I wrote a client for a card game called "Five card Jazz." It uses the HTTP protocol, which is more severe than the latency of the direct TCP protocol connection.

We use simple solitaire and draw animations to mask the problem of delay, so the problem of delay is only seen in a very bad connection. This method is also very typical: send the request at the same time to start playing the table animation, has played the last card to play until the end of the service to receive the data back. The battle effect of World of Warcraft is to use similar principles.

This also means that whether we are using TCP or UDP depends on whether we can hide the delay.

When does TCP expire

A game that uses TCP must be able to handle unexpected latency problems (typical of a card client, a sudden delay of one second, no complaints from the player), or a good way to mitigate latency problems.

But what if you're running a game that doesn't use any slow-down measures? Players ' action games for players usually fall into this category, but this is not limited to action-type games.

As an example:

I am currently writing a multiplayer game (War Arcana).

A common operation is that you move your character quickly through a world map full of war fog, but once you have explored it, the fog will be opened.

To ensure that the rules of the game prevent players from cheating, the server can only display information near the player's current location. This means that unlike World of Warcraft, a player cannot make a full action without getting a response from the server. Compared to five Card jazz, we have been very difficult even to allow 500 milliseconds of delay.

After realizing the prototype of the game, everything went very well in the LAN, but when we tested in the WiFi environment, the operation would get up intermittently or the delay would be high. After writing some test procedures, it was found that the occasional packet loss behavior occurs in the WiFi environment, and the server responds from 100-150 milliseconds to 1000-2000 milliseconds whenever a packet is dropped.

There is no way to circumvent this problem by bypassing the TCP setting.

We replaced the TCP code with a custom, reliable UDP implementation, reducing the latency of a large number of drops to just 50 milliseconds, even less than a back-and-forth delay in cases where TCP did not drop packets before. Of course, this can only be based on UDP, so that we have complete control over reliability.

Puzzle: Reliable UDP is just a simple implementation of TCP?

Have you ever heard of this saying: "Reliable UDP is like TCP, so use TCP."

The problem is that the argument is wrong. Reliable UDP is not like TCP at all, to implement a special blocking control. In fact, this is also the biggest reason you use reliable UDP instead of TCP to avoid TCP blocking control.

Another focus is on how reliable UDP reliability is guaranteed. There are a number of ways to achieve this. I really like the ideas in the Quake3 Network library code and they inspire me to use the UDP protocol in the War Arcana.

You can also use a number of UDP libraries that support reliable communication, and of course, in terms of reliability, it may be more generic and lose some performance benefits than the manual implementation of all of your code.

Bottom line

So what is UDP or TCP?

• If a stateless query is initiated intermittently by the client and the occasional delay is tolerated, then use Http/https .
• If both the client and the server can be contracted separately, but occasional delays can be tolerated (for example: Online card games, many MMO games), then use a tcp long connection .
• If both the client and the server can be contracted separately and cannot tolerate delays (for example, most multiplayer action games, some MMO games), then use UDP .

These should also be considered within: Your MMO client might first use HTTP to get the last update, and then use UDP to connect to the game server.

Never be afraid to use the best tools to solve problems.

Http UDP or TCP