As you correctly assume, 80... Connected means a (web) service is listening on port 80, and you were able to connect to it.
If the site is working well when using a browser (and also from other IP address)
connection reset by peer only gives you a feedback whatever you are trying to do, does not somewhat work. If you want more details, you can try to sniff the connection.
However, short of asking the owner of site for logs/debugging, I pretty much doubt you will get more data about the reasons behind it being reset otherwise.
As for the causes, it might be that they have rules to not accept your user agent/spiders/have specific pages/or configurations that trow purposefully that error or also block you after n tries/pages in a defined time frame (defined by them).
As commented before, this is more related to specific site security measures and configurations than a Unix issue per se.
For listening to the actual HTTP requests, you can also run in your machine:
# ngrep -q "." "port 80"
# ngrep -q "." "port 80 and host www.jdfschool.com"
Mind you that depending also on configurations, HTML, DNS and infra-structure setup, it is not a given the second
ngrep will listen to all HTTP requests.
As @muru states in comments, using
wget -v http://www.jdfschool.com
also might output more useful data.
As talked before, the odds of pinpoint exactly why is happening is slim. (In Apache web servers it is common to setup mod_evasive and mod_security to curb on spiders/abusive behaviour, for instance)
TLDR From the point of view of the site owner, what is happening to your command might well be intended behaviour.