If you are creating a vanilla request / response web application, the basics will be:
How does http / s work in general
An example http server is so common in the node world, because unlike another web language such as php, your node application does not live “inside” the apache web server or the like. In fact, you are creating a working web server that will return responses based on requests. This is a completely different way of organizing the program than the typical "embed your html / php / any files in the apache root directory" and go. The power of node is that it requires something like creating a web / tcp / udp / cli server. Trivializes many unpleasant hard parts such as thread pools, event loops, locks, etc.
Sessions / cookies / POST + GET
Because you will have to deal with these things more manually (at least until you write a module or select a module to handle it). Many of the candidates I call on the phone cannot determine for me the inner workings of how a typical language handles their session repository. They just know that they capture the value of X in the variable Y and its availability throughout the session. Actually there is a cookie that receives a set that refers to a file / database / somewhere, somewhere by session ID. In node, you pull these values from the http headers yourself (or the module does it for you) and builds on top of the more basic http building blocks. The same applies to POST and GET data.
As the saying goes, you can use a framework like express - http://expressjs.com/ , and it will handle a lot of things for you. However, its still raw enough (which most noderers prefer imo), which you can get in internal HTTP requests.
Constancy
Most web applications will require some kind of database. Relational databases such as mysql is one way around this - many node-takers prefer something like mongodb because it gives them a bit more freedom, like schemas + migration and a bit more javascript (because everything looks like JSON ) Fortunately, this is not what you need to do to make a tough and quick choice, because the community has many client libraries for shared databases.
Non-blocking methodology
As some others have said, this is something that can bring your mind to a certain extent. In many other languages, if you do not use a specific non-blocking structure, such as twisted in python, or eventmachine in ruby, you write code that is synchronous in almost all cases. This means that when you request information about your database, you do it as follows:
result = query("SELECT * FROM users"); console.log(results); console.log("howdy");
Instead, in node (or other frameworks that support callback / event based io), you will most likely write code that looks like this:
query("SELECT * FROM users", function(result){
In the first example (from the synchronous world), 'howdy' will be printed after the results. In the second (asynchronous) example, "howdy" is printed before the results.
This may seem complicated when you have to perform many synchronous operations, depending on each other. When you get to this point, it's time to look at the flow control libraries, such as https://github.com/caolan/async - they provide tools for the sequence of these operations, so your code does not look ridiculously nested.
Clearly, this is a broad question. Personally, I think you should just dive and give it all the twist. This is a really good way to learn this stuff.