Are there any major differences when we talk about "socket programming" compared to "network programming"?
Are there some topics that cover "network programming" but not "socket programming"?
Socket programming (at least as the term is normally used) is programming to one specific network API. Sockets support IP-based protocols (primarily TCP and UDP)1.
Network programming can be done using various other APIs. Windows has a number of protocol-independent APIs such as the WNet* and Net* functions. Older versions of Windows also used NetBIOS/NetBEUI (NetBIOS End User Interface), and most supported (and probably still do) IPX/SPX (an old Netware protocol).
Most current network programming, however, is done either using sockets directly, or using various other layers on top of sockets (e.g., quite a lot is done over HTTP, which is normally implemented with TCP over sockets). TCP/IP and UDP/IP (as well as a number of other IP-based protocols) are done primarily via the sockets interface. In theory, other programming interfaces could be used, but in practice sockets seem to be sufficient, so there's not a lot of interest in replacing it. I should, however, mention that Windows sockets (WinSock) have quite a few extensions that are more or less unique to Windows. I suppose it's open to some argument whether code that uses these extensions really qualifies as "sockets" code or not -- they are extensions based on the same concepts, but code that uses them isn't normally portable to other systems. I guess whether it qualifies as "sockets" or no depends primarily on whether you think of sockets more as a concept, or a very specific set of functions, parameters, etc.
Edit (in reply to comment):
It's a bit hard to say whether "knowing sockets" implies knowing "everything" about TCP and UDP. Let's consider just one small piece of things: one typical demo program for sockets is creating a client/server chat program. The client connects to the server, and when the user on one client types something, it gets forwarded to the other clients that are connected to the same server. Each client displays what comes in from the server, and lets the user type in messages to be sent to the other clients.
At the same time, consider what a "real" chat program like AIM, Windows Messenger, iChat, etc. involves. To handle not only text, but voice, video, file transfers, groups, lists, etc., a typical program probably involves a dozen different standards, including such things as SIP, STUN, TURN, RTCP, RTP, XAMPP, mDNS, etc.
IMO, somebody who "knows sockets" should be able to code up the first (demo-level, text-only) chat program in a few hours without spending much time in help files (and such) doing research. Unless they claimed at least some prior experience working on a "real" chat program, I wouldn't expect them to even know which RFCs/standards applied to such things though.
The same applies in general: given the number of RFCs (and various other standards) that get applied to all the different things people do over networks, it's unreasonable to expect anybody to have memorized all of them. Nonetheless, if you have a set of requirements for something that you'd expect people to be able to handle in a "local" program easily, just adding "over the network" as a requirement shouldn't normally add a tremendous amount of difficulty (though dealing with issues like network latency might).
1 Sockets on Unix also support Unix-family sockets, but these are (at least normally) used for intra-machine IPC, not networking.
"network programming" will require some networking technology - for example, RPC. Sockets (most likely you mean BSD sockets) are an example of such technology. So "socket programming" is a subset of "network programming".