RDP, also known as the Remote Desktop Protocol is a specially designed tool to access and use a remote desktop over intranet or internet using some specific port.
Remote Desktop Protocol (RDP) is a proprietary protocol developed by Microsoft, which provides a user with a graphical interface to connect to another computer over a network connection. The user employs RDP client software for this purpose, while the other computer must run RDP server software.
5 Benefits of Using RDP:
Deliver solutions to devices that may not have the processing power or capacity to run the applications natively.
Deliver Windows based applications to iOS, Android, Windows and even thin client devices.
Provide more compute resources to an application without having to upgrade everyone’s devices. This gives you the ability to reduce the cost of the end user devices knowing that when users need more compute power, the compute power can be associated with the actual workloads that need it.
Data can be stored in the cloud. If the end user device fails, or is lost or stolen, your data remains safe.
Configuration time is greatly reduced for new devices. Since the applications or desktop are delivered from the cloud and not are not stored on the local device, once a new device is setup, users can just reconnect to their remote apps or desktops and go back to work.
Features of RDP
32-bit color support. 8-, 15-, 16-, and 24-bit color are also supported.
128-bit encryption, using the RC4 encryption algorithm, as of Version 6.. TLS support since version 5.2.
Audio Redirection allows users to process audio on a remote desktop and have the sound redirected to their local computer.
File System Redirection allows users to use their local files on a remote desktop within the terminal session.
Printer Redirection allows users to use their local printer within the terminal session as they would with a locally- or network-shared printer.
Port Redirection allows applications running within the terminal session to access local serial and parallel ports directly.
The remote computer and the local computer can share the clipboard.
Microsoft introduced the following features with the release of RDP 6.0 in 2006:
Seamless Windows: remote applications can run on a client machine that is served by a Remote Desktop connection. It is available since RDP 6.
Remote Programs: application publishing with client-side file-type associations.
Terminal Services Gateway: enables the ability to use a front-end IIS server to accept connections (over port 443) for back-end Terminal Services servers via an https connection, similar to how RPC over https allows Outlook clients to connect to a back-end Exchange 2003 server. Requires Windows Server 2008.
Network Level Authentication
Support for remoting the Aero Glass Theme (or Composed Desktop), including ClearType font-smoothing technology.
Support for remoting Windows Presentation Foundation applications: compatible clients that have .NET Framework 3.0 support can display full Windows Presentation Foundation effects on a local machine.
Rewrite of device redirection to be more general-purpose, allowing a greater variety of devices to be accessed.
Fully configurable and scriptable via Windows Management Instrumentation.
Improved bandwidth tuning for RDP clients.
Support for Transport Layer Security (TLS) 1.0 on both server and client ends (can be negotiated if both parties agree, but not mandatory in a default configuration of any version of Windows).
Multiple monitor support for allowing one session to use multiple monitors on the client (disables desktop composition)
Release 7.1 of RDP in 2010 introduced the following feature:
RemoteFX: RemoteFX provides virtualized GPU support and host-side encoding; it ships as part of Windows Server 2008 R2 SP1.
Myths About RDP!
As the use of RDP increased, it increased the myths about the RDP too. So we gathered some studies that are officially confirmed by Microsoft RDP team too, and have jotted down 10 myths about RDP
1) RDP is pretty slow because it has to scrape the screen and can only send giant bitmaps
This is a common misconception. While many alternative protocols are principally screen scrapers, RDP uses sophisticated techniques to get much better performance than can be obtained with a simple screen scraping approach.
To drill into this it helps to first talk a little about what screen scraping really means (i.e. what RDP does not do today) and why it can be slow: In a screen scraping protocol the server side has to ‘poll’ screen contents frequently to see if anything has changed. Screen scraping polling involves frequent and costly memory ‘scrapes’ of screen content and then scanning through a lot of memory (a typical 1600×1200 by 32bpp screen is about 7MB of data) to see what parts may have changed. This burns up a lot of CPU cycles and leaves the protocol with few options but to send large resulting bitmaps down to the client.
So what does RDP do different today and why is it faster?
RDP uses presentation virtualization to enable a much better end-user experience, scalability and bandwidth utilization. RDP plugs into the Windows graphics system the same way a real display driver does, except that, instead of being a driver for a physical video card, RDP is a virtual display driver. Instead of sending drawing operations to a physical hardware GPU, RDP makes intelligent decisions about how to encode those commands into the RDP wire format. This can range from encoding bitmaps to, in many cases, encoding much smaller display commands such as “Draw line from point 1 to point 2” or “Render this text at this location.”
To illustrate some of the benefits on CPU load, terminal servers today can scale to many hundreds of users. In some of our scalability tests we see that even with hundreds of users connecting to one server running knowledge worker apps (e.g. Word, Outlook, Excel) the total CPU load consumed by RDP to encode and transmit the graphics is only a few percent of the whole system CPU load!
With this approach RDP avoids the costs of screen scraping and has a lot more flexibility in encoding the display as either bitmaps or a stream of commands to get the best possible performance.
2) RDP uses a lot of bandwidth
In many common and important scenarios such as knowledge worker applications and line of business app centralization RDP’s bandwidth usage is very low (on the order of Kbps per user depending on the app and scenario).
This is certainly much lower than many of the screen scraping approaches can hope to achieve (see point #1 above). More importantly it’s low enough that it provides a good experience for many users sharing the same network and datacenter infrastructure even when over a slow network.
So why has there been a perception that RDP uses a lot of bandwidth?
This is a good question and the answer probably lies in the fact that RDP does not use a constant amount of bandwidth; it actually tries to reduce bandwidth usage to 0 when nothing is changing on the screen. Bandwidth consumption only goes up in proportion to what is changing on screen. For instance, if you just run a line of business app with basic graphics and not much animation you may end up sending just a few Kbps of bandwidth down the wire. Of course if you start running animation-heavy applications or graphics your bandwidth usage will go up to support that scenario.
Your mileage will vary depending on your application and network conditions, so it’s important to actually measure empirically for your scenario but the whitepaper gives useful general trends.
3) Myth: I can’t get the same rich experience I get locally when working over RDP
This is also a misconception. RDP provides a scalable remoting experience. By default it cuts down on rich effects in the desktop and application experience in order to preserve bandwidth and save on server load (e.g. CPU, memory). However, if you want the highest end user experience it is possible to turn on many rich effects and display enhancements such as:
· The Aero theme with full glass and 3D effects (when connecting to Vista with RDP 6.1)
· 32-bit per pixel color
The key to enabling many of these effects is to run the Remote Desktop client, click Options, and then click the Experience tab. Here you can select and enable many high-end features. Note that in some cases your admin might have controlled access to these features with server-side group policies.
In many cases you can get a great end user experience with good parity to the local case.
We’re also constantly working to ‘close the gap’ between the local and remote experience and so we’re looking to improve the remote experience even more in future versions.
4) RDP can’t be tuned to get better performance
This is again a misconception. RDP has a set of defaults that tries to provide the best balance between bandwidth usage, the remote user experience, and server scalability. However, you can override many settings if you want to manually tune for a specific scenario and in some cases get very significant boosts in performance.
TIP: One of my favorite such settings is the ability to set policy on the server to optimize RDP compression. This can give you a boost of as much as 60% bandwidth improvement over previous versions of RDP. The tradeoff here is that you’d be consuming more server resources (such as memory and possibly CPU) to achieve that bandwidth reduction.
There is more information on tuning the bulk compressor as well as other RDP-tunable parameters such as cache sizes in the RDP Performance Whitepaper .
5) Using lower color depths — e.g. 8bpp — gives the best end user experience
This is a common misconception and was historically true, but not anymore!
The first version of RDP only supported 8bpp color. However, ever since Windows XP, RDP has supported up to 32bpp color.
The reason for this is that more and more apps have come to expect 32bpp mode as the default. Even the Windows Aero experience requires it.
Rather than deny this trend and create a difference between the local and remote experiences, we put a lot of effort into optimizing the 32bpp case to bring down its cost. This allows the user to have the flexibility to pick what is best for their scenario without necessarily having to incur a much bigger bandwidth cost.
In general I’d recommend attempting to run your scenario at 32bpp and measuring the resulting bandwidth to see if it’s acceptable for your scenario. It will usually give the best visual experience and in several cases will consume only a small percentage more data than 16bpp.
6) RDP is insecure; there is no encryption
To be clear, this is totally false! RDP has always supported strong encryption and is by default encrypted!
What has changed over the releases is the type of encryption we offer. The very first versions of RDP back in the Windows 2000 era had encryption that was based on SSL.
As early as Windows 2003 SP1 RDP we decided to introduce full-blown standards-based encryption (i.e. the same SSL as your browser uses to connect to your bank). SP1 did this by introducing standard SSL-encryption as an option.
Current versions of RDP have even stronger encryption and server authentication options out of the box. This is because they are built on top of a security mechanism in Windows called CredSSP which uses Kerberos or TLS (aka SSL) for authentication – when you use those settings RDP is using the same or stronger encryption that your browser uses when communicating with your bank.
7) RDP performance hasn’t changed much over the releases
False! We’re constantly working to improve RDP performance as well as adding a lot of great functionality to RDP in terms of features.
Every release since Windows 2000 has seen improved perf, i.e. there is a real benefit to upgrading to the latest client and server (e.g. RDP 6.1).
Here’s just one example of the bandwidth difference for a common scenario across several releases of RDP. We essentially have in these scenarios gains of between 8% to 45% bandwidth improvement from switching to the latest protocol. See the RDP Performance Whitepaper for more details on this data.
Going forward – We’re hard at work to continue that trend and bring even better innovations and improved remote experiences – see Asael’s post on some of the future upcoming improvements.
8) RDP is only used in Remote Desktop Services (formerly TS)
RDP is actually used under the hood in pretty much every Microsoft product that benefits from desktop or application remoting.
Just some examples of products or features you may not have known were built on top of RDP for their remoting needs:
· Remote Assistance
· Windows Media Center Extenders use RDP internally (including Xbox360)
· Windows Live Mesh
· Hyper-V Virtual Machine console
· Office Communications Server 2007 R2
· System Center Configuration Manager (SCCM)
If you’re interesting in seeing how RDP might be able to fit within your application, see the next point…
9)I can’t customize or program extensions to RDP
There are actually several useful ways to extend/or customize RDP:
· Programming the RDP Client: Host the RDP ActiveX control in your web page or application.
The Remote Desktop client in Windows is a great example of an application that hosts the RDP ActiveX control. This control is fully documented in MSDN . It’s possible for 3 rd party software developers to host this control in an app or a web page to provide desktop remoting as part of your larger app.
· Programming the RDP Server side: Use the Windows Desktop Sharing API
This blog post by Seenu has a lot of good detail and examples on how you can use our Windows Desktop Sharing API to write custom collaboration or desktop sharing applications, these APIs are all built on the same core RDP protocol that powers Windows Remote Desktop.
· Write a dynamic virtual channel extension to RDP
Probably the most powerful way to extend RDP is to actually write a virtual channel plug-in extension to RDP. This allows you to extend the protocol with your own bi-directional channel that can communicate from client to server. The possibilities are limitless but some examples include supporting new devices over RDP. We have a nice blog post with an overview of the dynamic virtual channel API or the docs are in MSDN .
10)The RDP protocol is not publicly documented
If you’re curious to learn more about very low-level technical details of RDP, we have thousands of pages of detailed specifications up on MSDN. For example, you can see the documents for the core protocol sequence and basic graphics here .
Are you looking to setup a RDP?
Our team can help you setting up a Remote Desktop at cheaper rates and provide you a highly available PC.
You can opt to get a Remote Desktop by connecting with ushere
M/s VIKASH TECH has a team of trained and certified consultants having rich experience in deploying server virtualization solutions offered by VMware, Citrix, Microsoft, Red Hat, ProXMox etc.. While multiple Virtual Machine’s deployment is seen as a challenge in corporate environments, we provide onsite solutions to our clients as well as remote solutions round the clock ensuring high availability of infrastructure at all times…[Read More]
Download our official app from play store and stay tuned with the latest updates over latest blogs, career opportunities and service offerings from M/s VIKASH TECH.