How does Server know window size for TCP Header?
The Window Size field in the TCP packet header is the number of bytes the sender will buffer for the response. Basically, during the handshake each side will say how large its receive window is. That is, the Window Size field in a packet sent by the client, tells the server how much data the client can receive and thus how much the server can send before the client would need to drop packets. Symmetrically for the packets the server sends to the client. See the flow control section for details on how the window size changes. Of course, see the relevant RFCs for the authoritative recommendations. 

As far as how the initial receive window is calculated, this is based on local resources and policies. Clearly, the initial receive window shouldn't be set to be larger than the amount of buffer memory you have. For a specific connection, larger is better for throughput if packets aren't being dropped, but larger packets are more likely to be dropped and when they are dropped require more data to be resent. RFC3390 presents a recommendation for what the initial receive window size should be assuming local resource limitations aren't a concern. This link describes what the Linux 2.6 kernel did (at least for RedHat distributions), though it may be out of date.

There is a different thing called the congestion window which each host may maintain itself as an estimate for how much data it can reliably send. This isn't communicated since it's unlikely there's anything the receiving end can do about it as it may well be intermediate nodes in the network that are limiting the rate. Again, this is an estimate and many variations of TCP are due to different strategies to estimate this value. Hosts don't have to agree on these congestion control algorithms for TCP to work.