The Reliability of Network Connections: Understanding TCP and VPNs

TCP, or Transmission Control Protocol, is a widely used protocol that ensures reliable data transfer over the internet. It does this by sending packets of data, verifying receipt of each packet, and retransmitting lost or corrupted packets. This process involves adjusting both the window size and the re-transmission timer on the fly to find the best performance for that network at that point. TCP is designed to handle unreliable networks, as packets may get lost or arrive out of sequence.

One reason why TCP works so well is its use of sequence numbers to reorder packets. When a packet arrives, TCP can correctly place it in the correct order by comparing the sequence number with the expected sequence number. This ensures that data is delivered in the correct order, even if some packets are lost or delayed. Additionally, TCP uses acknowledgements to confirm receipt of each packet, allowing the sender to know when a packet has been received successfully.

However, using TCP for virtual private networks (VPNs) can be more complicated than expected. When creating a VPN connection, data is wrapped in a TCP header and then in an IP packet header, which are then sent over a secure connection. This setup guarantees that every byte of data will arrive in the correct order, as TCP expects packets to be delivered reliably.

But what happens when the lower-level network connection becomes unreliable? In the case of a VPN using TCP, the upper-level TCP connection (TCP1) is protected by the lower-level TCP connection (TCP2). If packets are lost or arrive out of sequence at the lower level, TCP2 will ask for retransmission. This process is then passed up to TCP1, which adjusts its own sending speed in response.

This can lead to a situation where both algorithms start to fight each other. TCP1 will continue to send more packets, thinking some are getting lost, while TCP2 works to ensure they arrive in the correct order. As a result, performance of the network connection drops due to this competition between the two algorithms.

In contrast, UDP (User Datagram Protocol) is often used for VPNs because it provides similar assumptions as TCP but is simpler and more straightforward. When using UDP, packets are not guaranteed to be delivered or arrive in the correct order. However, UDP does allow multiple connections between machines, which can be useful in certain situations.

Another advantage of using UDP for VPNs is that it eliminates some of the complexity associated with using TCP. In particular, UDP eliminates the need for retransmissions and sequence numbering, which simplifies the overall process. While this means that UDP cannot guarantee reliable data transfer, its simplicity makes it an attractive choice for many applications.

In addition to providing a secure connection between two machines, VPNs also provide access to the internet via a router. The router acts as a firewall to prevent unauthorized access and encrypts all traffic using a shared session key (K-A-T). This ensures that data remains confidential and protected from eavesdropping or interception.

Overall, understanding how TCP and UDP work together in VPNs is crucial for designing and implementing reliable and secure network connections. While TCP provides guaranteed reliability and order of delivery, its complexity can lead to issues if the lower-level network connection becomes unreliable. By using UDP and simplifying the process, VPNs can provide faster and more straightforward connectivity while still maintaining essential security features.

When it comes to connecting to a business corporate network over the internet from home, creating a reliable TCP-based VPN is often the best choice. This involves establishing a secure connection between two machines using TCP and IP packets, which ensures that every byte of data will arrive in the correct order. By using this protocol, individuals can access resources on the corporate network or send data out to others over the internet.

However, as we've seen, there are potential challenges when using TCP for VPNs. When lower-level connections become unreliable, TCP algorithms may start to fight each other, leading to performance issues and packet loss. To mitigate this risk, some VPN services may use UDP instead of TCP. While this eliminates some complexity, it also means that packets are not guaranteed to be delivered or arrive in the correct order.

Regardless of whether a TCP-based or UDP-based VPN is chosen, encrypting all traffic using a shared session key (K-A-T) is essential for maintaining security and confidentiality. This ensures that data remains protected from eavesdropping or interception by unauthorized parties.

In conclusion, understanding how TCP and UDP work together in VPNs is crucial for designing reliable and secure network connections. While TCP provides guaranteed reliability and order of delivery, its complexity can lead to issues if the lower-level network connection becomes unreliable. By using UDP and simplifying the process, VPNs can provide faster and more straightforward connectivity while still maintaining essential security features.

"WEBVTTKind: captionsLanguage: enso we're going to follow up a bit on the vpn video we did the other day one of the things i mentioned in that video is how vpns often use udp or raw ip sockets to send the data rather than using tcp to communicate which is what lots of other protocols like http and so on use to communicate i thought it'd be a good idea to follow up on why they use udp rather than tcp because if they did use tcp you would suffer from what's been dubbed the tcp meltdown problem and so it's a good idea to look at this because we actually get to see a lot of how the internet works and how we make sure that the data that's sent from your from the server to the client gets there reliably or vice versa so to understand what's going on it helps to sort of think about how the internet works now the internet is built around the internet protocol ip which is designed to enable a computer to send a packet of data so a small amount of data anywhere on the internet so you can take that piece of data it's a destination address of where it wants to go with source address and ip says i will send this packet out anywhere over the internet to where you want it to go so i can send it from my house to sean's house i can send it from my house to microsoft or apple service to get a web page whatever it is i want to do now ip says i will do my best to get this packet to you i will try and pass it on but something may go wrong i may have it may not get there and in that case ah oh well um it's what's called a best effort network ip doesn't guarantee that it will get your packet from point a your machine to point b the destination it says it'll do its best it's not what we call a reliable network a reliable network is one where when you send some data it'll guarantee that it'll be received or it'll tell you that it hasn't been received ip doesn't do that ip is the best effort network it'll do its best to get there and these days probably 99 out of 100 times whatever the percentages are the package will get there but occasionally there'll be a sort of splat of noise on the one of the networks somewhere that obliterates the packet a computer will have too many packets arriving at it and one will get dropped it just won't get there that's just the way the internet works it doesn't guarantee that your data will get from a to b now this sounds like it should be a problem but actually what we can do is we can build other things on top of that unreliable network which give us reliable transport so we can send things over that network but as it stands it's worth remembering this because this is part of the reason that we get this tcp meltdown problem ip is an unreliable network it also doesn't guarantee that the packets you send will arrive in the order that you send them and there's no correlation between the packets you send you send packet packet packet and they arrive at the other machines as separate packets it's up to the other machine to sort of understand how they get there and it's worth remembering these three things because these are part of the problem that leads to tcp meltdown so even though ip doesn't give us a reliable network this isn't a problem for the internet because we can build other things on top of that and one of the things that we use is tcp tcp over ip tcp stands for the transmission control protocol what tcp does is it uses ip packets in specific way between the two ends of the connection to guarantee a reliable connection between the two machines what this means is when you send data you can guarantee this will arrive in order down that tcp connection it'll guarantee that they will get there and they will correlate them together so you can open a connection between two machines and the data you sent down one will arrive to the program at the other as is expected so this is guaranteed by tcp and it does that by using the unreliable ip packets in a specific way but it's built on the assumption that ip is an unreliable network that the packets may get lost they may arrive out of order and so on so and it has to take that into account and again that comes down to part of what is the problem if you try and build a vpn on top of tcp so now that it doesn't work is that the performance drops and it'll become really really slow when actually you could get a much faster thing so what's going on well it's worth looking at actually how tcp works we can see that and then we can see what happens when we put one tcp connection inside another tcp connection which is what would happen if we ran a vpn over the top of a tcp connection when we send data over tcp connection we have a stream of data that we're going to send from one computer to the other abcde and so i'm going to send that in order it's going to arrive in order what tcp does is it breaks that up into a series of packets so we've got five packets what it does is it puts a tcp header which contains some information so that tcp can re assemble the stream at the other end so it adds an extra header in there so as well as the ip packet header we've also got a tcp packet header in there as well so i'm drawing this in red on top of the packet and then just to pick another color let's have a nice green you've got the sort of ip header on there as well so we've got a series of packets we want to say contain some data in this case number one two three four five and they're wrapped up in the tcp header and they're wrapped up in the ip header as well and then they're sent out over the internet but what does tcp need to do to make sure that it can reassemble this data in the right order well the first thing it does is in the tcp header it gives each packet a sequence number and this is just a number that increases each time it gets sent over the internet and now if these packets arrive in a different order say we get packet one packet two packet four packet five packet three when they arrive because they've perhaps taken different routes around the internet then the algorithm can reorder them just by sorting them into the right order because we can use the sequence number so it's relatively straightforward to solve the problem that the packets may arrive out of order because we can resequence them but how do we solve the problem that the packet may get lost well the answer is relatively straightforward let me start another diagram let's have a think about what we've got on our two machines we've got our sending machine here we'll call that s and we've got our receiving machine over here we'll call that r and this is going to send packets to the other machine so it'll send packet one over to the machine that'll take some time to get there but eventually it'll get there and then it will send packet two and then it will send packet three then it sends bracket four but let's say that gets lost in transmission it then sends packet five so we've got one two three four five and at the other end we received packet one packet two packet three and packet five now how does the tcp algorithm make sure that it gets all of them and it can send the data in the right order well it's really quite simple what happens is when the receiving machine has received a packet of data it sends back an acknowledgement package so it just says to the other machine yep i received packet one yep i've received packet two and at this point the sender knows the packet one's been received correctly it gets the acknowledgement from packet two it knows that's been received correctly it gets the acknowledgement from packet three knows that that's been received correctly but it never gets an acknowledgement from packet four because it was never received and then eventually you'll get an acknowledgement from packet five so if we send an acknowledgement of receipt we say to the thing that sent it yep i got packet one or whatever the sequence number we put on it yep i got packet two or whatever the sequence number i put on it then the other end knows that that's been received what does it do when they get lost well at the same time as transmitting a packet so when it transmits packet one it also puts a copy of packet one in what's called the retransmission queue and when it sends packet two it puts a copy of packet two in there and it puts packet three packet four and packet five and when it puts these packets on there it sets a countdown timer with them that after a certain amount of time will expire and at that point if it hasn't received the acknowledgement as soon as it's been lost re-transmitted and then restart the countdown again and so if the enhancement isn't received either because the packet didn't get there or because the acknowledgement got lost on the route which can happen that's not a problem then the packet will get sent again and because tcp keeps track of the sequence numbers if it gets duplicates if the acknowledgement gets lost that's not a problem either it can eventually will get all the packets and can resort them into order now it doesn't actually work exactly like this it's not sending a packet then waiting for acknowledgement and sending a packet what it uses is also a thing called a window on the receiving end which says you can send up to this many packets before i'll send an acknowledgement for you effectively it's a bit more complicated than that but that's the general gist so that you don't have to keep waiting for it and you can make the most use of the bandwidth between the two machines so there's a bit of optimizations there but you now have a problem how long do you wait before resetting that packet and how many packets do you allow to be built up in that window before you stop sending it this very much depends on your network conditions if you've got a very fast local area network waiting 30 seconds for a packet before you resent it is probably not using the network that well because if you haven't received the acknowledgement probably in a few micro second or few milliseconds chances are you're not going to receive that packet likewise waiting a few seconds on a very congested slow link particularly when tcp was creating the 80s perhaps a sort of 56 kilobit network link waiting a few seconds probably wouldn't be a good time either because the chances of the network is more loaded so what ccp does is it analyzes this thing as it starts sending data so it starts in the data out and you look at what's happening how long it's taking for the acknowledgements to be returned how quickly the window is getting filled up and so on and it adjusts both the window size and the re-transmission timer on the fly to find the best performance for that network at that point so that's what it's doing and it's doing that because it knows that the network is transmitting over is unreliable the packets may get lost and that they may arrive out of sequence so it can reorder them using the sequence numbers it sends acknowledgements and so on it knows that the packets may get lost as they're being transmitted it knows that they may arrive out of order so by giving the sequence numbers on there by using the acknowledgements back to the thing that was sending it it's able to correct for these things and analyze the network connections to make best use of the available network at that point in time and that generally works in most cases pretty well and the internet is generally able to utilize all the bandwidth that's available between two people when tcp works well we talked about in the previous video how i might connect using a virtual private network over the internet from my machine at home to my business corporate network that i want to access resources on or go out over the internet from that and so on so if i create my vpn using a tcp connection between my machine at home and the business corporate network i've created a reliable connection which guarantees that every byte of data i sent will arrive and it will arrive in the order i send it it's very different from what tcp is expecting when it sends packets out using ips expecting the exact opposite that when i send data they might get lost and that they might arrive out of order so what happens is i take the data i want to send in my virtual private network i wrap it up in the tcp header there and then wrap it up in an ip packet header and then i put that ip package into another tcp stream and that gets sent to the business network this is going to get complicated so let's call the ones at the very top tcp one they're the ones that are being sent over the virtual connection and the ones that are being used to form in the virtual connection were called tcp2 just give them different names so these tcp one packets get sent out and if everything's fine if the network is working fine it'll it'll generally work okay you can do this the packets will get there it's just that they can sometimes go horribly wrong now let's think what happens if at tcp 2 at the lower level on the virtual link tcp2 effectively a packet goes missing or it arrives out of order let's say packet goes missing that lower level tcp2 connection will ask for the packet to be resent and so it will send the data again however many times that's needed and so on until it gets sent across and it's then passed up to tcp one which gets it but tcp1 says hang on this didn't come as quickly as i expected and something's going on here and you'll probably find the sender at that point and said oh i haven't had the akka expected um this connection is a bit slow so i better slow down sending things out and because tcp2 had delayed this so it arrived in order it arrived at tcp one also delayed and so the sun says oh that packet was slow as well um and it might have already we tried to transmit this at the tcp one level which means there's more packets going to tcp two than the necessary and very quickly you find the two algorithms start to fight each other and tcp one's algorithm will start sending more packets thinking they're getting lost while cp2 will be doing its best to make sure they get there in the order that they're sent and so what will end up is that the performance will drop of your network connection because the two algorithms are trying to fight each other now if you use udp which is what most vpn things do udp doesn't provide any guarantees that packets will get there all it does is sort of multiplex things so you can have more than one connection between two machines it's got port numbers that know what you do that those packets can still get lost at the lower level so you only have one algorithm tcp one at the top would now be running over udp the packet gets lost tcp one knows it's got lost at the point it's got lost and so the algorithm works as expected because it's got the same assumptions that it's expecting underneath for the lower level network which is why wherever possible most vpns will use udp or ip packets because they provide the same level of assumptions that tcp is expecting it was built it's a bit more complicated that but you get the general gist of what's going on that will be the internet and so those machines can also access the internet via the router and the router can act as a firewall so that people can't get into it it's all going to be encrypted using the k-a-t session key we've just obtained so k-a-tso we're going to follow up a bit on the vpn video we did the other day one of the things i mentioned in that video is how vpns often use udp or raw ip sockets to send the data rather than using tcp to communicate which is what lots of other protocols like http and so on use to communicate i thought it'd be a good idea to follow up on why they use udp rather than tcp because if they did use tcp you would suffer from what's been dubbed the tcp meltdown problem and so it's a good idea to look at this because we actually get to see a lot of how the internet works and how we make sure that the data that's sent from your from the server to the client gets there reliably or vice versa so to understand what's going on it helps to sort of think about how the internet works now the internet is built around the internet protocol ip which is designed to enable a computer to send a packet of data so a small amount of data anywhere on the internet so you can take that piece of data it's a destination address of where it wants to go with source address and ip says i will send this packet out anywhere over the internet to where you want it to go so i can send it from my house to sean's house i can send it from my house to microsoft or apple service to get a web page whatever it is i want to do now ip says i will do my best to get this packet to you i will try and pass it on but something may go wrong i may have it may not get there and in that case ah oh well um it's what's called a best effort network ip doesn't guarantee that it will get your packet from point a your machine to point b the destination it says it'll do its best it's not what we call a reliable network a reliable network is one where when you send some data it'll guarantee that it'll be received or it'll tell you that it hasn't been received ip doesn't do that ip is the best effort network it'll do its best to get there and these days probably 99 out of 100 times whatever the percentages are the package will get there but occasionally there'll be a sort of splat of noise on the one of the networks somewhere that obliterates the packet a computer will have too many packets arriving at it and one will get dropped it just won't get there that's just the way the internet works it doesn't guarantee that your data will get from a to b now this sounds like it should be a problem but actually what we can do is we can build other things on top of that unreliable network which give us reliable transport so we can send things over that network but as it stands it's worth remembering this because this is part of the reason that we get this tcp meltdown problem ip is an unreliable network it also doesn't guarantee that the packets you send will arrive in the order that you send them and there's no correlation between the packets you send you send packet packet packet and they arrive at the other machines as separate packets it's up to the other machine to sort of understand how they get there and it's worth remembering these three things because these are part of the problem that leads to tcp meltdown so even though ip doesn't give us a reliable network this isn't a problem for the internet because we can build other things on top of that and one of the things that we use is tcp tcp over ip tcp stands for the transmission control protocol what tcp does is it uses ip packets in specific way between the two ends of the connection to guarantee a reliable connection between the two machines what this means is when you send data you can guarantee this will arrive in order down that tcp connection it'll guarantee that they will get there and they will correlate them together so you can open a connection between two machines and the data you sent down one will arrive to the program at the other as is expected so this is guaranteed by tcp and it does that by using the unreliable ip packets in a specific way but it's built on the assumption that ip is an unreliable network that the packets may get lost they may arrive out of order and so on so and it has to take that into account and again that comes down to part of what is the problem if you try and build a vpn on top of tcp so now that it doesn't work is that the performance drops and it'll become really really slow when actually you could get a much faster thing so what's going on well it's worth looking at actually how tcp works we can see that and then we can see what happens when we put one tcp connection inside another tcp connection which is what would happen if we ran a vpn over the top of a tcp connection when we send data over tcp connection we have a stream of data that we're going to send from one computer to the other abcde and so i'm going to send that in order it's going to arrive in order what tcp does is it breaks that up into a series of packets so we've got five packets what it does is it puts a tcp header which contains some information so that tcp can re assemble the stream at the other end so it adds an extra header in there so as well as the ip packet header we've also got a tcp packet header in there as well so i'm drawing this in red on top of the packet and then just to pick another color let's have a nice green you've got the sort of ip header on there as well so we've got a series of packets we want to say contain some data in this case number one two three four five and they're wrapped up in the tcp header and they're wrapped up in the ip header as well and then they're sent out over the internet but what does tcp need to do to make sure that it can reassemble this data in the right order well the first thing it does is in the tcp header it gives each packet a sequence number and this is just a number that increases each time it gets sent over the internet and now if these packets arrive in a different order say we get packet one packet two packet four packet five packet three when they arrive because they've perhaps taken different routes around the internet then the algorithm can reorder them just by sorting them into the right order because we can use the sequence number so it's relatively straightforward to solve the problem that the packets may arrive out of order because we can resequence them but how do we solve the problem that the packet may get lost well the answer is relatively straightforward let me start another diagram let's have a think about what we've got on our two machines we've got our sending machine here we'll call that s and we've got our receiving machine over here we'll call that r and this is going to send packets to the other machine so it'll send packet one over to the machine that'll take some time to get there but eventually it'll get there and then it will send packet two and then it will send packet three then it sends bracket four but let's say that gets lost in transmission it then sends packet five so we've got one two three four five and at the other end we received packet one packet two packet three and packet five now how does the tcp algorithm make sure that it gets all of them and it can send the data in the right order well it's really quite simple what happens is when the receiving machine has received a packet of data it sends back an acknowledgement package so it just says to the other machine yep i received packet one yep i've received packet two and at this point the sender knows the packet one's been received correctly it gets the acknowledgement from packet two it knows that's been received correctly it gets the acknowledgement from packet three knows that that's been received correctly but it never gets an acknowledgement from packet four because it was never received and then eventually you'll get an acknowledgement from packet five so if we send an acknowledgement of receipt we say to the thing that sent it yep i got packet one or whatever the sequence number we put on it yep i got packet two or whatever the sequence number i put on it then the other end knows that that's been received what does it do when they get lost well at the same time as transmitting a packet so when it transmits packet one it also puts a copy of packet one in what's called the retransmission queue and when it sends packet two it puts a copy of packet two in there and it puts packet three packet four and packet five and when it puts these packets on there it sets a countdown timer with them that after a certain amount of time will expire and at that point if it hasn't received the acknowledgement as soon as it's been lost re-transmitted and then restart the countdown again and so if the enhancement isn't received either because the packet didn't get there or because the acknowledgement got lost on the route which can happen that's not a problem then the packet will get sent again and because tcp keeps track of the sequence numbers if it gets duplicates if the acknowledgement gets lost that's not a problem either it can eventually will get all the packets and can resort them into order now it doesn't actually work exactly like this it's not sending a packet then waiting for acknowledgement and sending a packet what it uses is also a thing called a window on the receiving end which says you can send up to this many packets before i'll send an acknowledgement for you effectively it's a bit more complicated than that but that's the general gist so that you don't have to keep waiting for it and you can make the most use of the bandwidth between the two machines so there's a bit of optimizations there but you now have a problem how long do you wait before resetting that packet and how many packets do you allow to be built up in that window before you stop sending it this very much depends on your network conditions if you've got a very fast local area network waiting 30 seconds for a packet before you resent it is probably not using the network that well because if you haven't received the acknowledgement probably in a few micro second or few milliseconds chances are you're not going to receive that packet likewise waiting a few seconds on a very congested slow link particularly when tcp was creating the 80s perhaps a sort of 56 kilobit network link waiting a few seconds probably wouldn't be a good time either because the chances of the network is more loaded so what ccp does is it analyzes this thing as it starts sending data so it starts in the data out and you look at what's happening how long it's taking for the acknowledgements to be returned how quickly the window is getting filled up and so on and it adjusts both the window size and the re-transmission timer on the fly to find the best performance for that network at that point so that's what it's doing and it's doing that because it knows that the network is transmitting over is unreliable the packets may get lost and that they may arrive out of sequence so it can reorder them using the sequence numbers it sends acknowledgements and so on it knows that the packets may get lost as they're being transmitted it knows that they may arrive out of order so by giving the sequence numbers on there by using the acknowledgements back to the thing that was sending it it's able to correct for these things and analyze the network connections to make best use of the available network at that point in time and that generally works in most cases pretty well and the internet is generally able to utilize all the bandwidth that's available between two people when tcp works well we talked about in the previous video how i might connect using a virtual private network over the internet from my machine at home to my business corporate network that i want to access resources on or go out over the internet from that and so on so if i create my vpn using a tcp connection between my machine at home and the business corporate network i've created a reliable connection which guarantees that every byte of data i sent will arrive and it will arrive in the order i send it it's very different from what tcp is expecting when it sends packets out using ips expecting the exact opposite that when i send data they might get lost and that they might arrive out of order so what happens is i take the data i want to send in my virtual private network i wrap it up in the tcp header there and then wrap it up in an ip packet header and then i put that ip package into another tcp stream and that gets sent to the business network this is going to get complicated so let's call the ones at the very top tcp one they're the ones that are being sent over the virtual connection and the ones that are being used to form in the virtual connection were called tcp2 just give them different names so these tcp one packets get sent out and if everything's fine if the network is working fine it'll it'll generally work okay you can do this the packets will get there it's just that they can sometimes go horribly wrong now let's think what happens if at tcp 2 at the lower level on the virtual link tcp2 effectively a packet goes missing or it arrives out of order let's say packet goes missing that lower level tcp2 connection will ask for the packet to be resent and so it will send the data again however many times that's needed and so on until it gets sent across and it's then passed up to tcp one which gets it but tcp1 says hang on this didn't come as quickly as i expected and something's going on here and you'll probably find the sender at that point and said oh i haven't had the akka expected um this connection is a bit slow so i better slow down sending things out and because tcp2 had delayed this so it arrived in order it arrived at tcp one also delayed and so the sun says oh that packet was slow as well um and it might have already we tried to transmit this at the tcp one level which means there's more packets going to tcp two than the necessary and very quickly you find the two algorithms start to fight each other and tcp one's algorithm will start sending more packets thinking they're getting lost while cp2 will be doing its best to make sure they get there in the order that they're sent and so what will end up is that the performance will drop of your network connection because the two algorithms are trying to fight each other now if you use udp which is what most vpn things do udp doesn't provide any guarantees that packets will get there all it does is sort of multiplex things so you can have more than one connection between two machines it's got port numbers that know what you do that those packets can still get lost at the lower level so you only have one algorithm tcp one at the top would now be running over udp the packet gets lost tcp one knows it's got lost at the point it's got lost and so the algorithm works as expected because it's got the same assumptions that it's expecting underneath for the lower level network which is why wherever possible most vpns will use udp or ip packets because they provide the same level of assumptions that tcp is expecting it was built it's a bit more complicated that but you get the general gist of what's going on that will be the internet and so those machines can also access the internet via the router and the router can act as a firewall so that people can't get into it it's all going to be encrypted using the k-a-t session key we've just obtained so k-a-t\n"