# data[].attributes.body
Uma rede informática é um conjunto de computadores interligados que partilham recursos entre si. Estes recursos podem incluir arquivos, impressoras e conexão com a internet.

# data[].attributes.body
As primeiras redes de computadores surgiram na década de 1960 e 1970, com o desenvolvimento da ARPANET nos Estados Unidos. Esta rede foi a precursora da atual internet.

# data[].attributes.attachment_link.readable_text
The Advanced Research Projects Agency Network ( ARPANET) was the first wide-area packet-switched network with distributed control and one of the first networks to implement the TCP/IP protocol suite. Both technologies became the technical foundation of the Internet. The ARPANET was established by the Advanced Research Projects Agency (ARPA) of the United States Department of Defense.

Building on the ideas of J. C. R. Licklider, Bob Taylor initiated the ARPANET project in 1966 to enable access to remote computers. Taylor appointed Larry Roberts as program manager. Roberts made the key decisions about the network design. He incorporated Donald Davies' concepts and designs for packet switching, and sought input from Paul Baran. ARPA awarded the contract to build the network to Bolt Beranek & Newman who developed the first protocol for the network. Roberts engaged Leonard Kleinrock at UCLA to develop mathematical methods for analyzing the packet network technology.

The first computers were connected in 1969 and the Network Control Program was implemented in 1970. The network was declared operational in 1971. Further software development enabled remote login, file transfer and email. The network expanded rapidly and operational control passed to the Defense Communications Agency in 1975.

Internetworking research in the early 1970s led by Bob Kahn at DARPA and Vint Cerf at Stanford University and later DARPA formulated the Transmission Control Program, which incorporated concepts from the French CYCLADES project. As this work progressed, a protocol was developed by which multiple separate networks could be joined into a network of networks. Version 4 of TCP/IP was installed in the ARPANET for production use in January 1983 after the Department of Defense made it standard for all military computer networking.

Access to the ARPANET was expanded in 1981, when the National Science Foundation (NSF) funded the Computer Science Network (CSNET). In the early 1980s, the NSF funded the establishment of national supercomputing centers at several universities, and provided network access and network interconnectivity with the NSFNET project in 1986. The ARPANET was formally decommissioned in 1990, after partnerships with the telecommunication and computer industry had assured private sector expansion and future commercialization of an expanded world-wide network, known as the Internet.

Historically, voice and data communications were based on methods of circuit switching, as exemplified in the traditional telephone network, wherein each telephone call is allocated a dedicated, end to end, electronic connection between the two communicating stations. The connection is established by switching systems that connected multiple intermediate call legs between these systems for the duration of the call.

The traditional model of the circuit-switched telecommunication network was challenged in the early 1960s by Paul Baran at the RAND Corporation, who had been researching systems that could sustain operation during partial destruction, such as by nuclear war. He developed the theoretical model of distributed adaptive message block switching. However, the telecommunication establishment rejected the development in favor of existing models. Donald Davies at the United Kingdom's National Physical Laboratory (NPL) independently arrived at a similar concept in 1965.

The earliest ideas for a computer network intended to allow general communications among computer users were formulated by computer scientist J. C. R. Licklider of Bolt, Beranek and Newman (BBN), in April 1963, in memoranda discussing the concept of the " Intergalactic Computer Network". Those ideas encompassed many of the features of the contemporary Internet. In October 1963, Licklider was appointed head of the Behavioral Sciences and Command and Control programs at the Defense Department's Advanced Research Projects Agency (ARPA). He convinced Ivan Sutherland and Bob Taylor that this network concept was very important and merited development, although Licklider left ARPA before any contracts were assigned for development.

Sutherland and Taylor continued their interest in creating the network, in part, to allow ARPA-sponsored researchers at various corporate and academic locales to utilize computers provided by ARPA, and, in part, to quickly distribute new software and other computer science results. Taylor had three computer terminals in his office, each connected to separate computers, which ARPA was funding: one for the System Development Corporation (SDC) Q-32 in Santa Monica, one for Project Genie at the University of California, Berkeley, and another for Multics at the Massachusetts Institute of Technology. Taylor recalls the circumstance: "For each of these three terminals, I had three different sets of user commands. So, if I was talking online with someone at S.D.C., and I wanted to talk to someone I knew at Berkeley, or M.I.T., about this, I had to get up from the S.D.C. terminal, go over and log into the other terminal and get in touch with them. I said, "Oh Man!", it's obvious what to do: If you have these three terminals, there ought to be one terminal that goes anywhere you want to go. That idea is the ARPANET".

Donald Davies' work caught the attention of ARPANET developers at Symposium on Operating Systems Principles in October 1967. He gave the first public presentation, having coined the term packet switching, in August 1968 and incorporated it into the NPL network in England. The NPL network and ARPANET were the first two networks in the world to use packet switching, and were themselves interconnected in 1973. Roberts said the ARPANET and other packet switching networks built in the 1970s were similar "in nearly all respects" to Davies' original 1965 design.

In February 1966, Bob Taylor successfully lobbied ARPA's Director Charles M. Herzfeld to fund a network project. Herzfeld redirected funds in the amount of one million dollars from a ballistic missile defense program to Taylor's budget. Taylor hired Larry Roberts as a program manager in the ARPA Information Processing Techniques Office in January 1967 to work on the ARPANET.

Roberts asked Frank Westervelt to explore the initial design questions for a network. In April 1967, ARPA held a design session on technical standards. The initial standards for identification and authentication of users, transmission of characters, and error checking and retransmission procedures were discussed. Roberts' proposal was that all mainframe computers would connect to one another directly. The other investigators were reluctant to dedicate these computing resources to network administration. Wesley Clark proposed minicomputers should be used as an interface to create a message switching network. Roberts modified the ARPANET plan to incorporate Clark's suggestion and named the minicomputers Interface Message Processors (IMPs).

The plan was presented at the inaugural Symposium on Operating Systems Principles in October 1967. Donald Davies' work on packet switching and the NPL network, presented by a colleague ( Roger Scantlebury), came to the attention of the ARPA investigators at this conference. Roberts applied Davies' concept of packet switching for the ARPANET, and sought input from Paul Baran. The NPL network was using line speeds of 768 kbit/s, and the proposed line speed for the ARPANET was upgraded from 2.4 kbit/s to 50 kbit/s.

By mid-1968, Roberts and Barry Wessler wrote a final version of the IMP specification based on a Stanford Research Institute (SRI) report that ARPA commissioned to write detailed specifications describing the ARPANET communications network. Roberts gave a report to Taylor on 3 June, who approved it on 21 June. After approval by ARPA, a Request for Quotation (RFQ) was issued for 140 potential bidders. Most computer science companies regarded the ARPA proposal as outlandish, and only twelve submitted bids to build a network; of the twelve, ARPA regarded only four as top-rank contractors. At year's end, ARPA considered only two contractors, and awarded the contract to build the network to Bolt, Beranek and Newman Inc. (BBN) on 7 April 1969.

The initial, seven-person BBN team were much aided by the technical specificity of their response to the ARPA RFQ, and thus quickly produced the first working system. This team was led by Frank Heart and included Robert Kahn. The BBN-proposed network closely followed Roberts' ARPA plan: a network composed of small computers called Interface Message Processors (or IMPs), similar to the later concept of routers, that functioned as gateways interconnecting local resources. At each site, the IMPs performed store-and-forward packet switching functions, and were interconnected with leased lines via telecommunication data sets ( modems), with initial data rates of . The host computers were connected to the IMPs via custom serial communication interfaces. The system, including the hardware and the packet switching software, was designed and installed in nine months. The BBN team continued to interact with the NPL team with meetings between them taking place in the U.S. and the U.K.

The first-generation IMPs were built by BBN Technologies using a rugged computer version of the Honeywell DDP-516 computer, configured with of expandable magnetic-core memory, and a 16-channel Direct Multiplex Control (DMC) direct memory access unit. The DMC established custom interfaces with each of the host computers and modems. In addition to the front-panel lamps, the DDP-516 computer also features a special set of 24 indicator lamps showing the status of the IMP communication channels. Each IMP could support up to four local hosts, and could communicate with up to six remote IMPs via early Digital Signal 0 leased telephone lines. The network connected one computer in Utah with three in California. Later, the Department of Defense allowed the universities to join the network for sharing hardware and software resources.

According to Charles Herzfeld, ARPA Director (1965-1967):

The ARPANET was not started to create a Command and Control System that would survive a nuclear attack, as many now claim. To build such a system was, clearly, a major military need, but it was not ARPA's mission to do this; in fact, we would have been severely criticized had we tried. Rather, the ARPANET came out of our frustration that there were only a limited number of large, powerful research computers in the country, and that many research investigators, who should have access to them, were geographically separated from them.

Nonetheless, according to Stephen J. Lukasik, who as Deputy Director (1967-1970) and Director of DARPA (1970-1975) was "the person who signed most of the checks for Arpanet's development":

The goal was to exploit new computer technologies to meet the needs of military command and control against nuclear threats, achieve survivable control of US nuclear forces, and improve military tactical and management decision making.

The ARPANET incorporated distributed computation, and frequent re-computation, of routing tables. This increased the survivability of the network in the face of significant interruption. Automatic routing was technically challenging at the time. The ARPANET was designed to survive subordinate-network losses, since the principal reason was that the switching nodes and network links were unreliable, even without any nuclear attacks.

The Internet Society agrees with Herzfeld in a footnote in their online article, A Brief History of the Internet:

It was from the RAND study that the false rumor started, claiming that the ARPANET was somehow related to building a network resistant to nuclear war. This was never true of the ARPANET, but was an aspect of the earlier RAND study of secure communication. The later work on internetworking did emphasize robustness and survivability, including the capability to withstand losses of large portions of the underlying networks.

Paul Baran, the first to put forward a theoretical model for communication using packet switching, conducted the RAND study referenced above. Though the ARPANET did not exactly share Baran's project's goal, he said his work did contribute to the development of the ARPANET. Minutes taken by Elmer Shapiro of Stanford Research Institute at the ARPANET design meeting of 9-10 October 1967 indicate that a version of Baran's routing method ("hot potato") may be used, consistent with the NPL team's proposal at the Symposium on Operating System Principles in Gatlinburg.

The first four nodes were designated as a testbed for developing and debugging the 1822 protocol, which was a major undertaking. While they were connected electronically in 1969, network applications were not possible until the Network Control Program was implemented in 1970 enabling the first two host-host protocols, remote login ( Telnet) and file transfer ( FTP) which were specified and implemented between 1969 and 1973. The network was declared operational in 1971. Network traffic began to grow once email was established at the majority of sites by around 1973.

The first four IMPs were:

University of California, Los Angeles (UCLA), where Leonard Kleinrock had established a Network Measurement Center, with an SDS Sigma 7 being the first computer attached to it;

The Augmentation Research Center at Stanford Research Institute (now SRI International), where Douglas Engelbart had created the new NLS system, an early hypertext system, and would run the Network Information Center (NIC), with the SDS 940 that ran NLS, named "Genie", being the first host attached;

University of California, Santa Barbara (UCSB), with the Culler-Fried Interactive Mathematics Center's IBM 360/75, running OS/MVT being the machine attached;

The University of Utah School of Computing, where Ivan Sutherland had moved, running a DEC PDP-10 operating on TENEX.

The first successful host to host connection on the ARPANET was made between Stanford Research Institute (SRI) and UCLA, by SRI programmer Bill Duvall and UCLA student programmer Charley Kline, at 10:30 pm PST on 29 October 1969 (6:30 UTC on 30 October 1969). Kline connected from UCLA's SDS Sigma 7 Host computer (in Boelter Hall room 3420) to the Stanford Research Institute's SDS 940 Host computer. Kline typed the command "login," but initially the SDS 940 crashed after he typed two characters. About an hour later, after Duvall adjusted parameters on the machine, Kline tried again and successfully logged in. Hence, the first two characters successfully transmitted over the ARPANET were "lo". The first permanent ARPANET link was established on 21 November 1969, between the IMP at UCLA and the IMP at the Stanford Research Institute. By 5 December 1969, the initial four-node network was established.

Elizabeth Feinler created the first Resource Handbook for ARPANET in 1969 which led to the development of the ARPANET directory. The directory, built by Feinler and a team made it possible to navigate the ARPANET.

Roberts engaged Howard Frank to consult on the topological design of the network. Frank made recommendations to increase throughput and reduce costs in a scaled-up network. By March 1970, the ARPANET reached the East Coast of the United States, when an IMP at BBN in Cambridge, Massachusetts was connected to the network. Thereafter, the ARPANET grew: 9 IMPs by June 1970 and 13 IMPs by December 1970, then 18 by September 1971 (when the network included 23 university and government hosts); 29 IMPs by August 1972, and 40 by September 1973. By June 1974, there were 46 IMPs, and in July 1975, the network numbered 57 IMPs. By 1981, the number was 213 host computers, with another host connecting approximately every twenty days.

Support for inter-IMP circuits of up to 230.4 kbit/s was added in 1970, although considerations of cost and IMP processing power meant this capability was not actively used.

Larry Roberts saw the ARPANET and NPL projects as complementary and sought in 1970 to connect them via a satellite link. Peter Kirstein's research group at University College London (UCL) was subsequently chosen in 1971 in place of NPL for the UK connection. In June 1973, a transatlantic satellite link connected ARPANET to the Norwegian Seismic Array (NORSAR), via the Tanum Earth Station in Sweden, and onward via a terrestrial circuit to a TIP at UCL. UCL provided a gateway for an interconnection with the NPL network, the first interconnected network, and subsequently the SRCnet, the forerunner of UK's JANET network.

1971 saw the start of the use of the non-ruggedized (and therefore significantly lighter) Honeywell 316 as an IMP. It could also be configured as a Terminal Interface Processor (TIP), which provided terminal server support for up to 63 ASCII serial terminals through a multi-line controller in place of one of the hosts. The 316 featured a greater degree of integration than the 516, which made it less expensive and easier to maintain. The 316 was configured with 40 kB of core memory for a TIP. The size of core memory was later increased, to 32 kB for the IMPs, and 56 kB for TIPs, in 1973.

In 1975, BBN introduced IMP software running on the Pluribus multi-processor. These appeared in a few sites. In 1981, BBN introduced IMP software running on its own C/30 processor product.

In 1968, Roberts contracted with Kleinrock to measure the performance of the network and find areas for improvement. Building on his earlier work on queueing theory, Kleinrock specified mathematical models of the performance of packet-switched networks, which underpinned the development of the ARPANET as it expanded rapidly in the early 1970s.

The ARPANET was a research project that was communications-oriented, rather than user-oriented in design. Nonetheless, in the summer of 1975, the ARPANET was declared "operational". The Defense Communications Agency took control since ARPA was intended to fund advanced research. At about this time, the first ARPANET encryption devices were deployed to support classified traffic.

The transatlantic connectivity with NORSAR and UCL later evolved into the SATNET. The ARPANET, SATNET and PRNET were interconnected in 1977.

The ARPANET Completion Report, published in 1981 jointly by BBN and ARPA, concludes that:

... it is somewhat fitting to end on the note that the ARPANET program has had a strong and direct feedback into the support and strength of computer science, from which the network, itself, sprang.

CSNET, expansion

Access to the ARPANET was expanded in 1981, when the National Science Foundation (NSF) funded the Computer Science Network (CSNET).

Adoption of TCP/IP

The DoD made TCP/IP standard for all military computer networking in 1980. NORSAR and University College London left the ARPANET and began using TCP/IP over SATNET in early 1982.

On January 1, 1983, known as flag day, TCP/IP protocols became the standard for the ARPANET, replacing the earlier Network Control Program.

MILNET, phasing out

In September 1984 work was completed on restructuring the ARPANET giving U.S. military sites their own Military Network ( MILNET) for unclassified defense department communications. Both networks carried unclassified information, and were connected at a small number of controlled gateways which would allow total separation in the event of an emergency. MILNET was part of the Defense Data Network (DDN).

Separating the civil and military networks reduced the 113-node ARPANET by 68 nodes. After MILNET was split away, the ARPANET would continue be used as an Internet backbone for researchers, but be slowly phased out.

In 1985, the National Science Foundation (NSF) funded the establishment of national supercomputing centers at several universities, and provided network access and network interconnectivity with the NSFNET project in 1986. NSFNET became the Internet backbone for government agencies and universities.

The ARPANET project was formally decommissioned in 1990. The original IMPs and TIPs were phased out as the ARPANET was shut down after the introduction of the NSFNet, but some IMPs remained in service as late as July 1990.

In the wake of the decommissioning of the ARPANET on 28 February 1990, Vinton Cerf wrote the following lamentation, entitled "Requiem of the ARPANET":

It was the first, and being first, was best,
but now we lay it down to ever rest.
Now pause with me a moment, shed some tears.
For auld lang syne, for love, for years and years
of faithful service, duty done, I weep.
Lay down thy packet, now, O friend, and sleep.

- Vinton Cerf

The ARPANET was related to many other research projects, which either influenced the ARPANET design, or which were ancillary projects or spun out of the ARPANET.

Senator Al Gore authored the High Performance Computing and Communication Act of 1991, commonly referred to as "The Gore Bill", after hearing the 1988 concept for a National Research Network submitted to Congress by a group chaired by Leonard Kleinrock. The bill was passed on 9 December 1991 and led to the National Information Infrastructure (NII) which Gore called the information superhighway.

Inter-networking protocols developed by ARPA and implemented on the ARPANET paved the way for future commercialization of a new world-wide network, known as the Internet.

The ARPANET project was honored with two IEEE Milestones, both dedicated in 2009.

Because it was never a goal for the ARPANET to support IMPs from vendors other than BBN, the IMP-to-IMP protocol and message format were not standardized. However, the IMPs did nonetheless communicate amongst themselves to perform link-state routing, to do reliable forwarding of messages, and to provide remote monitoring and management functions to ARPANET's Network Control Center. Initially, each IMP had a 6-bit identifier, and supported up to 4 hosts, which were identified with a 2-bit index. An ARPANET host address, therefore, consisted of both the port index on its IMP and the identifier of the IMP, which was written with either port/IMP notation or as a single byte; for example, the address of MIT-DMG (notable for hosting development of Zork) could be written as either 1/6 or 70. An upgrade in early 1976 extended the host and IMP numbering to 8-bit and 16-bit, respectively.

In addition to primary routing and forwarding responsibilities, the IMP ran several background programs, titled TTY, DEBUG, PARAMETER-CHANGE, DISCARD, TRACE, and STATISTICS. These were given host numbers in order to be addressed directly and provided functions independently of any connected host. For example, "TTY" allowed an on-site operator to send ARPANET packets manually via the teletype connected directly to the IMP.

The starting point for host-to-host communication on the ARPANET in 1969 was the 1822 protocol, which defined the transmission of messages to an IMP. The message format was designed to work unambiguously with a broad range of computer architectures. An 1822 message essentially consisted of a message type, a numeric host address, and a data field. To send a data message to another host, the transmitting host formatted a data message containing the destination host's address and the data message being sent, and then transmitted the message through the 1822 hardware interface. The IMP then delivered the message to its destination address, either by delivering it to a locally connected host, or by delivering it to another IMP. When the message was ultimately delivered to the destination host, the receiving IMP would transmit a Ready for Next Message (RFNM) acknowledgement to the sending, host IMP.

Unlike modern Internet datagrams, the ARPANET was designed to reliably transmit 1822 messages, and to inform the host computer when it loses a message; the contemporary IP is unreliable, whereas the TCP is reliable. Nonetheless, the 1822 protocol proved inadequate for handling multiple connections among different applications residing in a host computer. This problem was addressed with the Network Control Program (NCP), which provided a standard method to establish reliable, flow-controlled, bidirectional communications links among different processes in different host computers. The NCP interface allowed application software to connect across the ARPANET by implementing higher-level communication protocols, an early example of the protocol layering concept later incorporated in the OSI model.

NCP was developed under the leadership of Stephen D. Crocker, then a graduate student at UCLA. Crocker created and led the Network Working Group (NWG) which was made up of a collection of graduate students at universities and research laboratories sponsored by ARPA to carry out the development of the ARPANET and the software for the host computers that supported applications. The various application protocols such as TELNET for remote time-sharing access, File Transfer Protocol (FTP) and rudimentary electronic mail protocols were developed and eventually ported to run over the TCP/IP protocol suite or replaced in the case of email by the Simple Mail Transport Protocol.

Steve Crocker formed a "Networking Working Group" in 1969 with Vint Cerf, who also joined an International Networking Working Group in 1972. These groups considered how to interconnect packet switching networks with different specifications, that is, internetworking. Stephen J. Lukasik directed DARPA to focus on internetworking research in the early 1970s. Research led by Bob Kahn at DARPA and Vint Cerf at Stanford University and later DARPA resulted in the formulation of the Transmission Control Program, which incorporated concepts from the French CYCLADES project directed by Louis Pouzin. Its specification was written by Cerf with Yogen Dalal and Carl Sunshine in December 1974 ( RFC 675). The following year, testing began through concurrent implementations at Stanford, BBN and University College London. At first a monolithic design, the software was redesigned as a modular protocol stack in version 3 in 1978. Version 4 was installed in the ARPANET for production use in January 1983, replacing NCP. The development of the complete Internet protocol suite by 1989, as outlined in RFC 1122 and RFC 1123, and partnerships with the telecommunication and computer industry laid the foundation for the adoption of TCP/IP as a comprehensive protocol suite as the core component of the emerging Internet.

NCP provided a standard set of network services that could be shared by several applications running on a single host computer. This led to the evolution of application protocols that operated, more or less, independently of the underlying network service, and permitted independent advances in the underlying protocols.

Telnet was developed in 1969 beginning with RFC 15, extended in RFC 855.

The original specification for the File Transfer Protocol was written by Abhay Bhushan and published as RFC 114 on 16 April 1971. By 1973, the File Transfer Protocol (FTP) specification had been defined ( RFC 354) and implemented, enabling file transfers over the ARPANET.

In 1971, Ray Tomlinson, of BBN sent the first network e-mail ( RFC 524, RFC 561). Within a few years, e-mail came to represent a very large part of the overall ARPANET traffic.

The Network Voice Protocol (NVP) specifications were defined in 1977 ( RFC 741), and implemented. But, because of technical shortcomings, conference calls over the ARPANET never worked well; the contemporary Voice over Internet Protocol (packet voice) was decades away.

The Purdy Polynomial hash algorithm was developed for the ARPANET to protect passwords in 1971 at the request of Larry Roberts, head of ARPA at that time. It computed a polynomial of degree 2 ²⁴ + 17 modulo the 64-bit prime p = 2 ⁶⁴ − 59. The algorithm was later used by Digital Equipment Corporation (DEC) to hash passwords in the VMS operating system and is still being used for this purpose.[citation needed ]

Because of its government funding, certain forms of traffic were discouraged or prohibited.

Leonard Kleinrock claims to have committed the first illegal act on the Internet, having sent a request for return of his electric razor after a meeting in England in 1973. At the time, use of the ARPANET for personal reasons was unlawful.

In 1978, against the rules of the network, Gary Thuerk of Digital Equipment Corporation (DEC) sent out the first mass email to approximately 400 potential clients via the ARPANET. He claims that this resulted in $13 million worth of sales in DEC products, and highlighted the potential of email marketing.

A 1982 handbook on computing at MIT's AI Lab stated regarding network etiquette:

It is considered illegal to use the ARPANet for anything which is not in direct support of Government business ... personal messages to other ARPANet subscribers (for example, to arrange a get-together or check and say a friendly hello) are generally not considered harmful ... Sending electronic mail over the ARPANet for commercial profit or political purposes is both anti-social and illegal. By sending such messages, you can offend many people, and it is possible to get MIT in serious trouble with the Government agencies which manage the ARPANet.

Computer Networks: The Heralds of Resource Sharing, a 30-minute documentary film[91] featuring Fernando J. Corbató, J. C. R. Licklider, Lawrence G. Roberts, Robert Kahn, Frank Heart, William R. Sutherland, Richard W. Watson, John R. Pasta, Donald W. Davies, and economist, George W. Mitchell.

"Scenario", an episode of the U.S. television sitcom Benson (season 6, episode 20-dated February 1985), was the first incidence of a popular TV show directly referencing the Internet or its progenitors. The show includes a scene in which the ARPANET is accessed.[92]

There is an electronic music artist known as "Arpanet", Gerald Donald, one of the members of Drexciya. The artist's 2002 album Wireless Internet features commentary on the expansion of the internet via wireless communication, with songs such as NTT DoCoMo, dedicated to the mobile communications giant based in Japan.[citation needed ]

Thomas Pynchon mentions the ARPANET in his 2009 novel Inherent Vice, which is set in Los Angeles in 1970, and in his 2013 novel Bleeding Edge.[citation needed ]

The 1993 television series The X-Files featured the ARPANET in a season 5 episode, titled "Unusual Suspects". John Fitzgerald Byers offers to help Susan Modeski (known as Holly ... "just like the sugar") by hacking into the ARPANET to obtain sensitive information.[93][better source needed ]

In the spy-drama television series The Americans, a Russian scientist defector offers access to ARPANET to the Russians in a plea to not be repatriated (Season 2 Episode 5 "The Deal"). Episode 7 of Season 2 is named 'ARPANET' and features Russian infiltration to bug the network.

In the television series Person of Interest, main character Harold Finch hacked the ARPANET in 1980 using a homemade computer during his first efforts to build a prototype of the Machine.[94][95] This corresponds with the real life virus that occurred in October of that year that temporarily halted ARPANET functions.[96][97] The ARPANET hack was first discussed in the episode 2PiR (stylised 2 R) where a computer science teacher called it the most famous hack in history and one that was never solved. Finch later mentioned it to Person of Interest Caleb Phipps and his role was first indicated when he showed knowledge that it was done by "a kid with a homemade computer" which Phipps, who had researched the hack, had never heard before.

In the third season of the television series Halt and Catch Fire, the character Joe MacMillan explores the potential commercialization of the ARPANET.

1. ^

2. ^ "An Internet Pioneer Ponders the Next Revolution". The New York Times. 20 December 1999. Mr. Taylor wrote a white paper in 1968, a year before the network was created, with another ARPA research director, J. C. R. Licklider. The paper, "The Computer as a Communications Device," was one of the first clear statements about the potential of a computer network.

3. ^ Hafner, Katie (30 December 2018). "Lawrence Roberts, Who Helped Design Internet's Precursor, Dies at 81". The New York Times. ISSN 0362-4331. He decided to use packet switching as the underlying technology of the Arpanet; it remains central to the function of the internet. And it was Dr. Roberts's decision to build a network that distributed control of the network across multiple computers. Distributed networking remains another foundation of today's internet.

4. ^ "Computer Pioneers - Donald W. Davies". IEEE Computer Society. In 1965, Davies pioneered new concepts for computer communications in a form to which he gave the name "packet switching." ... The design of the ARPA network (ArpaNet) was entirely changed to adopt this technique.; "A Flaw In The Design". The Washington Post. 30 May 2015. The Internet was born of a big idea: Messages could be chopped into chunks, sent through a network in a series of transmissions, then reassembled by destination computers quickly and efficiently. Historians credit seminal insights to Welsh scientist Donald W. Davies and American engineer Paul Baran. ... The most important institutional force ... was the Pentagon's Advanced Research Projects Agency (ARPA) ... as ARPA began work on a groundbreaking computer network, the agency recruited scientists affiliated with the nation's top universities.

5. Abbate, Janet (2000). Inventing the Internet. Cambridge, MA: MIT Press. pp. 39, 57-58. ISBN 978-0-2625-1115-5. Baran proposed a "distributed adaptive message-block network" [in the early 1960s] ... Roberts recruited Baran to advise the ARPANET planning group on distributed communications and packet switching. ... Roberts awarded a contract to Leonard Kleinrock of UCLA to create theoretical models of the network and to analyze its actual performance.

6. ^ Roberts, Dr. Lawrence G. (November 1978). "The Evolution of Packet Switching" (PDF). IEEE Invited Paper. Archived from the original (PDF) on 31 December 2018. Significant aspects of the network's internal operation, such as routing, flow control, software design, and network control were developed by a BBN team consisting of Frank Heart, Robert Kahn, Severo Omstein, William Crowther, and David Walden

7. Cerf, V.; Kahn, R. (1974). "A Protocol for Packet Network Intercommunication" (PDF). IEEE Transactions on Communications. 22 (5): 637-648. doi:10.1109/TCOM.1974.1092259. ISSN 1558-0857. The authors wish to thank a number of colleagues for helpful comments during early discussions of international network protocols, especially R. Metcalfe, R. Scantlebury, D. Walden, and H. Zimmerman; D. Davies and L. Pouzin who constructively commented on the fragmentation and accounting issues; and S. Crocker who commented on the creation and destruction of associations.

8. ^ R. Oppliger (2001). Internet and Intranet Security. Artech House. p. 12. ISBN 978-1-58053-166-5.

9. ^ Fidler, Bradley; Mundy, Russ (November 2020). The Creation and Administration of Unique Identifiers, 1967-2017 (PDF). 1.2: ICANN. p. 8.

10. ^ Scantlebury, Roger (25 June 2013). "Internet pioneers airbrushed from history". The Guardian.

11. ^

12. ^ Smith, Ed; Miller, Chris; Norton, Jim. "Packet Switching: The first steps on the road to the information society".

13. ; ^ "Donald Davies". internethalloffame.org.

14. ^

15. ^

16. ^ Roberts, Dr. Lawrence G. (November 1978). "The Evolution of Packet Switching" (PDF). IEEE Invited Paper. Archived from the original (PDF) on 31 December 2018. In nearly all respects, Davies' original proposal, developed in late 1965, was similar to the actual networks being built today.

17. ^ Markoff, John, Innovator who helped create PC, Internet and the mouse, New York Times, 15 April 2017, p.A1

18. ^ "SRI Project 5890-1; Networking (Reports on Meetings).[1967]". web.stanford.edu. W. Clark's message switching proposal (appended to Taylor's letter of April 24, 1967 to Engelbart)were reviewed.

19. ^ Roberts, Lawrence (1967). "Multiple computer networks and intercomputer communication" (PDF). Multiple Computer Networks and Intercomputer Communications. pp. 3.1-3.6. doi:10.1145/800001.811680. S2CID 17409102. Thus the set of IMP's, plus the telephone lines and data sets would constitute a message switching network

20. ^

21. ^ Cambell-Kelly, Martin (Autumn 2008). "Pioneer Profiles: Donald Davies". Computer Resurrection (44). ISSN 0958-7403.

22. ^ Hafner, Katie (25 June 2018). "Frank Heart, Who Linked Computers Before the Internet, Dies at 89". The New York Times. ISSN 0362-4331.

23. ^

24. ^

25. ^ Heart, Frank; Kahn, Robert; Ornstein, Severo; Crowther, William; Walden, David (1970). The Interface Message Processor for the ARPA Computer Network (PDF). 1970 Spring Joint Computer Conference. p. 565. doi:10.1145/1476936.1477021. S2CID 9647377.

26. ^

27. ^ (PDF) https://www.darpa.mil/attachments/DARPA_Directors_Sheet_20201.pdf.

28. ^ Lukasik, Stephen J. (2011). "Why the Arpanet Was Built". IEEE Annals of the History of Computing. 33 (3): 4-20. doi:10.1109/MAHC.2010.11. S2CID 16076315.

29. ^ Abbate, Janet (2000). Inventing the Internet. Cambridge, MA: MIT Press. pp. 194-195. ISBN 978-0-2625-1115-5.

30. ^ Baran, Paul (2002). "The beginnings of packet switching: some underlying concepts" (PDF). IEEE Communications Magazine. 40 (7): 42-48. doi:10.1109/MCOM.2002.1018006. ISSN 0163-6804. Essentially all the work was defined by 1961, and fleshed out and put into formal written form in 1962. The idea of hot potato routing dates from late 1960.

31. ^ Brand, Stewart (March 2001). "Founding Father". Wired. 9 (3).

32. ^ "Shapiro: Computer Network Meeting of October 9-10, 1967". stanford.edu.

33. ^ Cambell-Kelly, Martin (1987). "Data Communications at the National Physical Laboratory (1965-1975)". Annals of the History of Computing. 9 (3/4): 239.

34. ^ Chris Sutton (2 September 2004). "Internet Began 35 Years Ago at UCLA with First Message Ever Sent Between Two Computers". UCLA. Archived from the original on 8 March 2008.

35. ^ Weber, Marc (25 October 2019). "The First 50 Years Of Living Online: ARPANET and Internet". Computer History Museum blog.

36. ^ Kirstein, P.T. (1999). "Early experiences with the Arpanet and Internet in the United Kingdom". IEEE Annals of the History of Computing. 21 (1): 38-44. doi:10.1109/85.759368. ISSN 1934-1547. S2CID 1558618.

37. ^ Kirstein, Peter T. (July-September 2009). "The Early Days of the Arpanet". IEEE Annals of the History of Computing. 31 (3): 67. doi:10.1109/mahc.2009.35. ISSN 1058-6180.

38. ^ "Hobbes' Internet Timeline - the definitive ARPAnet & Internet history" (PDF). www.cs.kent.edu.

39. ^ Frank, Ronald A. (22 October 1975). "Security Problems Still Plague Packet-Switched Nets". Computerworld. IDG Enterprise: 18.

40. ^ "III". A History of the ARPANET: The First Decade (Report). Arlington, VA: Bolt, Beranek & Newman Inc. 1 April 1981. p. 132. section 2.3.4

41. ^ Leiner, Barry M.; Cerf, Vinton G.; Clark, David D.; Kahn, Robert E.; Kleinrock, Leonard; Lynch, Daniel C.; Postel, Jon; Roberts, Larry G.; Wolff, Stephen (7 October 2009). "A brief history of the internet". ACM SIGCOMM Computer Communication Review. 39 (5): 22-31. doi:10.1145/1629607.1629613. ISSN 0146-4833.

42. by Vinton Cerf, as told to Bernard Aboba (1993). "How the Internet Came to Be". Archived from the original on 26 September 2017. We began doing concurrent implementations at Stanford, BBN, and University College London. So effort at developing the Internet protocols was international from the beginning. ... Mar '82 - Norway leaves the ARPANET and become an Internet connection via TCP/IP over SATNET. Nov '82 - UCL leaves the ARPANET and becomes an Internet connection.

43. ^ Alex McKenzie; Dave Walden (1991). "ARPANET, the Defense Data Network, and Internet". The Froehlich/Kent Encyclopedia of Telecommunications. 1. CRC Press. pp. 341-375. ISBN 978-0-8247-2900-4.

44. ^

45. ^

46. ^

47. ^ McKenzie, Alexander (2011). "INWG and the Conception of the Internet: An Eyewitness Account". IEEE Annals of the History of Computing. 33 (1): 66-71. doi:10.1109/MAHC.2011.9. ISSN 1934-1547. S2CID 206443072.

48. ^ "The internet's fifth man". The Economist. 30 November 2013. ISSN 0013-0613. In the early 1970s Mr Pouzin created an innovative data network that linked locations in France, Italy and Britain. Its simplicity and efficiency pointed the way to a network that could connect not just dozens of machines, but millions of them. It captured the imagination of Dr Cerf and Dr Kahn, who included aspects of its design in the protocols that now power the internet.

49. ^

50. ^ Abbate, Janet (2000). Inventing the Internet. Cambridge, MA: MIT Press. pp. 106-111. ISBN 978-0-2625-1115-5. OCLC 44962566.

51. ^ Still, tapping into the ARPANET to fetch a shaver across international lines was a bit like being a stowaway on an aircraft carrier. The ARPANET was an official federal research facility, after all, and not something to be toyed with. Kleinrock had the feeling that the stunt he'd pulled was slightly out of bounds. 'It was a thrill. I felt I was stretching the Net'. - "Where Wizards Stay Up Late: The Origins of the Internet", Chapter 7.

52. ^ Stacy, Christopher C. (7 September 1982). "Getting Started Computing at the AI Lab". hdl:1721.1/41180.

53. ^

54. ^ The X-Files Season 5, Ep. 3 "Unusual Suspects".

55. Season 2, Episode 11 "2PiR" (stylised "2^ R")

56. ^ Season 3, Episode 12 "Aletheia"

57. ^ "BBC News - SCI/TECH - Hacking: A history". BBC.

58. ^ "Hobbes' Internet Timeline - the definitive ARPAnet & Internet history". zakon.org.

Norberg, Arthur L.; O'Neill, Judy E. (1996). Transforming Computer Technology: Information Processing for the Pentagon, 1962-1982. Johns Hopkins University. pp. 153-196. ISBN 978-0-8018-6369-1.

A History of the ARPANET: The First Decade (Report). Arlington, VA: Bolt, Beranek & Newman Inc. 1 April 1981.

Hafner, Katie; Lyon, Matthew (1996). Where Wizards Stay Up Late: The Origins of the Internet. Simon and Schuster. ISBN 978-0-7434-6837-4.

Abbate, Janet (2000). Inventing the Internet. Cambridge, MA: MIT Press. pp. 36-111. ISBN 978-0-2625-1115-5.

Banks, Michael A. (2008). On the Way to the Web: The Secret History of the Internet and Its Founders. APress/Springer Verlag. ISBN 978-1-4302-0869-3.

Salus, Peter H. (1 May 1995). Casting the Net: from ARPANET to Internet and Beyond. Addison-Wesley. ISBN 978-0-201-87674-1.

Waldrop, M. Mitchell (23 August 2001). The Dream Machine: J. C. R. Licklider and the Revolution That Made Computing Personal. New York: Viking. ISBN 978-0-670-89976-0.

"The Computer History Museum, SRI International, and BBN Celebrate the 40th Anniversary of First ARPANET Transmission". Computer History Museum. 27 October 2009.

Focuses on Kahn's role in the development of computer networking from 1967 through the early 1980s. Beginning with his work at Bolt Beranek and Newman (BBN), Kahn discusses his involvement as the ARPANET proposal was being written and then implemented, and his role in the public demonstration of the ARPANET. The interview continues into Kahn's involvement with networking when he moves to IPTO in 1972, where he was responsible for the administrative and technical evolution of the ARPANET, including programs in packet radio, the development of a new network protocol (TCP/IP), and the switch to TCP/IP to connect multiple networks.

Marill, Thomas; Roberts, Lawrence G. (1966). "Toward a cooperative network of time-shared computers". Proceedings of the November 7-10, 1966, fall joint computer conference (AFIPS '66 (Fall)). Association for Computing Machinery. pp. 425-431. doi:10.1145/1464291.1464336. S2CID 2051631. Archived from the original on 1 April 2002.

Roberts, Lawrence G. (1967). "Multiple computer networks and intercomputer communication". Proceedings of the first ACM symposium on Operating System Principles (SOSP '67). Association for Computing Machinery. pp. 3.1-3.6. doi:10.1145/800001.811680. S2CID 17409102. Archived from the original on 3 June 2002.

Davies, D.W.; Bartlett, K.A.; Scantlebury, R.A.; Wilkinson, P.T. (1967). "A digital communication network for computers giving rapid response at remote terminals". Proceedings of the first ACM symposium on Operating System Principles (SOSP '67). Association for Computing Machinery. pp. 2.1-2.17. doi:10.1145/800001.811669. S2CID 15215451.

Roberts, Lawrence G.; Wessler, Barry D. (1970). "Computer network development to achieve resource sharing". Proceedings of the May 5-7, 1970, Spring Joint Computer Conference (AFIPS '70 (Spring)). Association for Computing Machinery. pp. 543-9. doi:10.1145/1476936.1477020. S2CID 9343511.

Heart, Frank; Kahn, Robert; Ornstein, Severo; Crowther, William; Walden, David (1970). The Interface Message Processor for the ARPA Computer Network (PDF). 1970 Spring Joint Computer Conference. AFIPS Proc. 36. pp. 551-567. doi:10.1145/1476936.1477021.

Carr, Stephen; Crocker, Stephen; Cerf, Vinton (1970). Host-Host Communication Protocol in the ARPA Network. 1970 Spring Joint Computer Conference. AFIPS Proc. 36. pp. 589-598. doi:10.1145/1476936.1477024. RFC .

Ornstein, Severo; Heart, Frank; Crowther, William; Russell, S. B.; Rising, H. K.; Michel, A. (1972). The Terminal IMP for the ARPA Computer Network. 1972 Spring Joint Computer Conference. AFIPS Proc. 40. pp. 243-254. doi:10.1145/1478873.1478906.

McQuillan, John; Crowther, William; Cosell, Bernard; Walden, David; Heart, Frank (1972). Improvements in the Design and Performance of the ARPA Network. 1972 Fall Joint Computer Conference part II. AFIPS Proc. 41. pp. 741-754. doi:10.1145/1480083.1480096.

Heart, Frank; Kahn, Robert; Ornstein, Severo; Crowther, William; Walden, David (1970). The Interface Message Processor for the ARPA Computer Network (PDF). 1970 Spring Joint Computer Conference. AFIPS Proc. 36. pp. 551-567. doi:10.1145/1476936.1477021.

Carr, Stephen; Crocker, Stephen; Cerf, Vinton (1970). Host-Host Communication Protocol in the ARPA Network. 1970 Spring Joint Computer Conference. AFIPS Proc. 36. pp. 589-598. doi:10.1145/1476936.1477024. RFC .

Ornstein, Severo; Heart, Frank; Crowther, William; Russell, S. B.; Rising, H. K.; Michel, A. (1972). The Terminal IMP for the ARPA Computer Network. 1972 Spring Joint Computer Conference. AFIPS Proc. 40. pp. 243-254. doi:10.1145/1478873.1478906.

Feinler, E.; Postel, J. (1976). ARPANET Protocol Handbook. SRI International. OCLC 2817630. NTIS ADA027964.

Feinler, Elizabeth J.; Postel, Jonathan B. (January 1978). ARPANET Protocol Handbook. Menlo Park: Network Information Center (NIC), SRI International. ASIN B000EN742K. OCLC 7955574. NIC 7104, NTIS ADA052594.

Feinler, E.J.; Landsberden, J.M.; McGinnis, A.C. (1976). ARPANET Resource Handbook. Stanford Research Institute. OCLC 1110650114. NTIS ADA040452.

Roberts, Larry (November 1978). "The Evolution of Packet Switching". Proceedings of the IEEE. 66 (11): 1307-13. doi:10.1109/PROC.1978.11141. S2CID 26876676. Archived from the original on 24 March 2016.

Roberts, Larry (1986). "The ARPANET & Computer Networks". Proceedings of the ACM Conference on The history of personal workstations (HPW '86). Association for Computing Machinery. pp. 51-58. doi:10.1145/12178.12182. ISBN 978-0-89791-176-4. S2CID 24271168. Archived from the original on 24 March 2016.

# data[].attributes.attachment_link.description
The Advanced Research Projects Agency Network ( ARPANET) was the first wide-area packet-switched network with distributed control and one of the first networks to implement the TCP/IP protocol suite. Both technologies became the technical foundation of the Internet. The ARPANET was established by the Advanced Research Projects Agency (ARPA) of the United States Department of Defense.

# data[].attributes.body
As LANs (Local Area Networks) são redes que cobrem uma área geográfica pequena, como um escritório ou um edifício. São muito usadas em ambientes empresariais e domésticos.

# data[].attributes.body
As MANs (Metropolitan Area Networks) cobrem áreas geográficas maiores, como cidades. São utilizadas por provedores de serviços de internet para conectar várias LANs.

# data[].attributes.body
As WANs (Wide Area Networks) cobrem grandes áreas geográficas, como países ou continentes. A internet é o maior exemplo de uma WAN.

# data[].attributes.body
Roteadores são dispositivos que encaminham pacotes de dados entre redes diferentes. Eles desempenham um papel crucial na interligação de redes locais e na conexão à internet.

# data[].attributes.body
Switches são dispositivos de rede que conectam computadores dentro de uma mesma rede local. Eles facilitam a comunicação eficiente entre múltiplos dispositivos.

# data[].attributes.body
Os pontos de acesso são dispositivos que permitem aos dispositivos sem fio conectarem-se a uma rede com fio. São comumente usados em redes domésticas e empresariais.

# data[].attributes.body
O Protocolo de Internet (IP) é responsável por endereçar e encaminhar pacotes de dados na rede. Ele permite que os dispositivos identifiquem e se comuniquem uns com os outros.

# data[].attributes.attachment_link.description
In May 1974, the Institute of Electrical and Electronic Engineers (IEEE) published a paper entitled "A Protocol for Packet Network Intercommunication". The paper's authors, Vint Cerf and Bob Kahn, described an internetworking protocol for sharing resources using packet switching among network nodes.

# data[].attributes.body
O Protocolo de Controle de Transmissão (TCP) garante a entrega confiável de pacotes de dados na rede. Ele segue um modelo de conexão, onde a comunicação é estabelecida e mantida antes da transferência de dados.

# data[].attributes.attachment_link.title
Transmission Control Protocol - Wikipedia

# data[].attributes.attachment_link.description
The Transmission Control Protocol ( TCP) is one of the main protocols of the Internet protocol suite. It originated in the initial network implementation in which it complemented the Internet Protocol (IP). Therefore, the entire suite is commonly referred to as TCP/IP.

# data[].attributes.body
O Protocolo de Transferência de Hipertexto (HTTP) é usado para a transferência de páginas web na internet. Ele é a base da comunicação na World Wide Web.

# data[].attributes.attachment_link.readable_text
O Hypertext Transfer Protocol , sigla HTTP (em português Protocolo de Transferência de Hipertexto) é um protocolo de comunicação (na camada de aplicação segundo o Modelo OSI) utilizado para sistemas de informação de hipermídia, distribuídos e colaborativos. Ele é a base para a comunicação de dados da World Wide Web.

Coordenado pela World Wide Web Consortium e a Internet Engineering Task Force, culminou na publicação de uma série de Requests for Comments; mais notavelmente o RFC 2616, de junho de 1999, que definiu o HTTP/1.1. Em Junho de 2014 foram publicados 6 RFC's para maior clareza do protocolo HTTP/1.1. Em Março de 2015, foi divulgado o lançamento do HTTP/2. A atualização deixará o navegador com um tempo de resposta melhor e mais seguro. Ele também melhorará a navegação em smartphones. Os trabalhos no HTTP/3 já começaram e suas versões beta estão em teste por grandes empresas.

Para acedermos a outro documento a partir de uma palavra presente no documento actual podemos utilizar hiperligações (ou âncoras). Estes documentos se encontram no sítio com um endereço de página da Internet - e para acessá-los deve-se digitar o respectivo endereço, denominado URI ( Universal Resource Identifier ou Identificador Universal de Recurso), que não deve ser confundido com URL ( Universal Resource Locator ou Localizador Universal de Recurso), um tipo de URI que pode ser directamente localizado.

O HTTP funciona como um protocolo de requisição-resposta no modelo computacional cliente-servidor. Um navegador web, por exemplo, pode ser o cliente e uma aplicação em um computador que hospeda um sítio da web pode ser o servidor. O cliente submete uma mensagem de requisição HTTP para o servidor. O servidor, que fornece os recursos, como arquivos HTML e outros conteúdos, ou realiza outras funções de interesse do cliente, retorna uma mensagem resposta para o cliente. A resposta contém informações de estado completas sobre a requisição e pode também conter o conteúdo solicitado no corpo de sua mensagem.

Um navegador web é um exemplo de agente de usuário (AU). Outros tipos de agentes de usuário incluem o software de indexação usado por provedores de consulta ( web crawler), navegadores vocais, aplicações móveis e outros software que acessam, consomem ou exibem conteúdo web.

O HTTP é projetado para permitir intermediações de elementos de rede para melhorar ou habilitar comunicações entre clientes e servidores. Sites web de alto tráfego geralmente se beneficiam dos servidores de cache web que entregam conteúdo em nome de servidores de upstream para melhorar o tempo de resposta. Navegadores web armazenam os recursos web acessados anteriormente e reutilizam-nos quando possível para reduzir o tráfego de rede. Servidores proxy HTTP nas fronteiras de redes privadas podem facilitar a comunicação para o cliente sem um endereço globalmente roteável, transmitindo mensagens com servidores externos.

Basicamente, o HTTP define como clientes Web requisitam páginas Web aos servidores e como elas as transferem a clientes. Quando um usuário solicita uma página Web (acessa uma URL), o navegador envia ao servidor mensagens de requisição HTTP para os objetos da página. O servidor, por sua vez, recebe estas requisições e responde com mensagens de resposta HTTP que contém os objetos (...). O protocolo HTTP utiliza por padrão a porta 80 para comunicação (MACEDO et al., 2018).

Tim Berners-Lee na Campus Party Brasil em 2009.

O HyperText Transfer Protocol é um protocolo de aplicação responsável pelo tratamento de pedidos e respostas entre cliente e servidor na World Wide Web. Ele surgiu da necessidade de distribuir informações pela Internet e para que essa distribuição fosse possível foi necessário criar uma forma padronizada de comunicação entre os clientes e os servidores da Web e entendida por todos os computadores ligados à Internet. Com isso, o protocolo HTTP passou a ser utilizado para a comunicação entre computadores na Internet e a especificar como seriam realizadas as transações entre clientes e servidores, através do uso de regras básicas.

Este protocolo tem sido usado pela WWW desde 1990. A primeira versão de HTTP, chamada HTTP/0.9, era um protocolo simples para a transferência de dados no formato de texto ASCII pela Internet, através de um único método de requisição, chamado GET. A versão HTTP/1.0 foi desenvolvida entre 1992 e 1996 para suprir a necessidade de transferir não apenas texto. Com essa versão, o protocolo passou a transferir mensagens do tipo MIME44 ( Multipurpose Internet Mail Extension) e foram implementados novos métodos de requisição, chamados POST e HEAD.

No HTTP/1.1, versão do protocolo descrito na RFC 2616, foi desenvolvido um conjunto de implementações adicionais ao HTTP/1.0, como por exemplo: o uso de conexões persistentes; o uso de servidores que permitem uma melhor organização da ; novos métodos de requisições; entre outros. Afirma-se que o HTTP também é usado como um protocolo genérico para comunicação entre os agentes de utilizadores e proxies/ gateways com outros protocolos, como o SMTP, NNTP, FTP, Gopher, e WAIS, permitindo o acesso a recursos disponíveis em aplicações diversas.

O HTTP/2 foi publicado como RFC 7540 em maio de 2015.

O termo cookie é derivado do inglês que significa biscoito. Recebeu esse nome de uma antiga gíria usada pelos programadores que consistia em um programa que chamava um procedimento e recebia de volta algo que seria necessário apresentar novamente mais tarde para realizar algum trabalho. Foi criado pela Netscape para solucionar o problema do envio e solicitação de arquivos, que eram esquecidos pelo servidor e que poderiam ser usados por outros computadores com o mesmo IP conforme (TANEMBAUM, 2003), o que causava problemas, pois não se sabia na realidade se era ou não aquele usuário mesmo. Os cookies são arquivos ou strings e não são programas executáveis. Eles são tratados como dados pelo navegador, não existe nenhuma maneira dele ser usado como vírus, apesar de que podem ser explorados bugs no servidor e causar a ativação de um cookie como vírus, por um hacker. Basicamente ele é um grupo de dados trocados entre o servidor de páginas e o navegador colocado em um ficheiro criado no computador do usuário. Serve para manter a persistência das sessões HTTP. Ele funciona da seguinte forma: Um usuário solicita uma página da Web, nisso o servidor pode fornecer informações adicionais acompanhando a página solicitada. Essas informações podem incluir um cookie, um pequeno arquivo ou string (com quatro KB no máximo). Este cookie pode ter até 5 campos (figura abaixo): Domain, Path, Content, Expires, Secure. Domain informa de onde veio o cookie. O navegador confirma que os servidores estão enviando dados fieis a respeito de seu domínio. Cada domínio pode armazenar no máximo 20 cookies por cliente. O campo Path é um caminho na estrutura de diretórios do servidor que identifica as partes da árvore de arquivos do servidor que podem usar o cookie. Frequentemente, ele obtém o símbolo / (barra), que representa a árvore inteira. O campo Content utiliza a forma nome = valor, podendo o servidor definir da maneira que quiser tanto o valor quanto o nome, e é nele que fica armazenado o conteúdo do cookie. Expires é o campo que faz o cookie persistir, nele contém a data e o horário, e se ele estiver ausente o navegador descartara automaticamente após o termino da sessão. O último campo define se ele é seguro ou não.

Figura x: Alguns exemplos de cookie.↵Fonte: (TANEMBAUM, 2003).

O cookie é usado para identificar um usuário que configurou uma página web, para que na próxima vez que ele entrar ela esteja configurada do modo em que ele deixou. Pode ser usado também quando se faz a solicitação de armazenamento de senha, na vez posterior em que entrar no site, a sua senha será lembrada. É usado também em sites de compra, como e-commerce, armazenando os produtos que o cliente colocou no carrinho para que no final da compra não necessite fazer todo o processo novamente.

Um sistema de comunicação em rede possui diversos protocolos que trabalham em conjunto para o fornecimento de serviços. Para que o protocolo HTTP consiga transferir seus dados pela Web, é necessário que os protocolos TCP e IP ( Internet Protocol, Protocolo de Internet) tornem possível a conexão entre clientes e servidores através de TCP/IP.

De acordo com Fielding, o HTTP utiliza o modelo cliente-servidor, como a maioria dos protocolos de rede, baseando-se no paradigma de requisição e resposta. Um programa requisitante (cliente) estabelece uma conexão com um outro programa receptor (servidor) e envia-lhe uma requisição, contendo a URI, a versão do protocolo, uma mensagem MIME (padrão utilizado para codificar dados em formato de textos ASCII para serem transmitidos pela Internet) contendo os modificadores da requisição, informações sobre o cliente e, possivelmente, o conteúdo no corpo da mensagem.

O servidor responde com uma linha de status ( status line) incluindo sua versão de protocolo e com os códigos de erro informando se a operação foi bem sucedida ou fracasso, seguido pelas informações do servidor, metainformações da entidade e possível conteúdo no corpo da mensagem. Após o envio da resposta pelo servidor, encerra-se a conexão estabelecida.

O protocolo HTTP faz a comunicação entre o cliente e o servidor por meio de mensagens. O cliente envia uma mensagem de requisição de um recurso e o servidor envia uma mensagem de resposta ao cliente com a solicitação. Segundo Foscarini, os dois tipos de mensagens existentes no protocolo utilizam um formato genérico, definido na RFC 822, para a transferência de entidades.

Uma mensagem, tanto de requisição quanto de resposta, é composta, conforme definido na RFC 2616, por uma linha inicial, nenhuma ou mais linhas de cabeçalhos, uma linha em branco obrigatória finalizando o cabeçalho e por fim o corpo da mensagem, opcional em determinados casos. Nessa sessão serão apresentados os campos que compõem uma mensagem mais detalhadamente; ou seja, o HTTP apresenta o sítio ou local onde está a página da Internet.

O cabeçalho da mensagem () é utilizado para transmitir informações adicionais entre o cliente e o servidor. Ele é especificado imediatamente após a linha inicial da transação (método), tanto para a requisição do cliente quanto para a resposta do servidor, seguido de dois pontos (:) e um valor. Existem quatro tipos de cabeçalhos que poderão ser incluídos na mensagem os quais são: general-header, request-header, response-header e entity-header.

Esses cabeçalhos são utilizados para enviar informações adicionais sobre a mensagem transmitida ( general-header), a requisição e os clientes ( request-header) que comunicam suas configurações e os formatos de documentos desejados como resposta. Além disso, são utilizados pelo servidor ao retornar o recurso no qual foi requisitado pelo cliente, para transmitir informações que descrevem as configurações do servidor e do recurso identificado pelo URI de requisição, e que não pertence à linha de status ( response-header). Na RFC 2616, estão descritos todos os campos que pertencem a esses cabeçalhos.

Uma mensagem HTTP pode conter um corpo de dados que são enviados abaixo das linhas de cabeçalho. Em uma mensagem de resposta, o corpo da mensagem é o recurso que foi requisitado pelo cliente, ou ainda uma mensagem de erro, caso este recurso não seja possível. Já em uma mensagem de requisição, o corpo pode conter dados que serão enviados diretamente pelo usuário ou um arquivo que será enviado para o servidor. Quando uma mensagem HTTP tiver um corpo, poderão ser incluídos cabeçalhos de entidades que descrevem suas características, como por exemplo, o Content-Type que informa o tipo MIME dos dados no corpo da mensagem e o Content-Length que informa a quantidade de bytes que o corpo da mensagem contém. A tabela ao lado apresenta alguns tipos MIME.

De acordo com Fielding, uma mensagem de requisição do cliente é composta pelos seguintes campos: uma linha inicial ( Request-Line); linhas de cabeçalhos ( Request-header); uma linha em branco obrigatória e um corpo de mensagem opcional. A linha inicial de uma requisição é composta por três partes separadas por espaços: o método ( Method), a identificação do URI ( Request-URI) e a versão do HTTP ( HTTP-Version) utilizado.

Segundo Bastos & Ladeira, Request-URI é um identificador uniforme de recurso (Uniform Resource Identifier) que identifica sobre qual recurso será aplicada a requisição. No protocolo HTTP, o tipo de URI utilizado é chamado de URL (Uniform Resource Locator), composto pela identificação do protocolo, pelo endereço do computador servidor e pelo documento requisitado.

O protocolo HTTP define oito métodos (GET, HEAD, POST, PUT, DELETE, TRACE, OPTIONS e CONNECT) que indicam a ação a ser realizada no recurso especificado. Conforme Bastos e Ladeiras, o método determina o que o servidor deve fazer com o URL fornecido no momento da requisição de um recurso. Um servidor HTTP deve implementar ao menos os métodos GET e HEAD. Os métodos GET e POST são os que aparecem mais comumente durante o desenvolvimento web.

Uma solicitação HTTP, ou HTTP Request é uma maneira do navegador mostrar uma página da internet utilizando um dos oito métodos de solicitação do protocolo HTTP.

Além de solicitar um determinado arquivo, envia várias informação para o servidor, sendo elas: o seu IP, a versão do navegador que está usando, que página utilizou para pedir a HTTP Request e a idioma que você usa, entre outros.

Abaixo segue um exemplo de uma comunicação entre um cliente e um servidor HTTP. O servidor possui a URL www.exemplo.com, porta 80.

O pedido do cliente (seguido por uma linha em branco, de maneira que o pedido termina com um duplo, cada um composto por um carriage return seguido de um ):

GET /index.html HTTP/1.1
Host: www.exemplo.com

O cabeçalho Host reconhece vários diferentes nomes DNS que tenham o mesmo IP.

A resposta do servidor (seguida por uma linha em branco e o texto da página solicitada):

HTTP/1.1 200 OK
Date: Mon, 23 May 2005 22:38:34 GMT
Server: Apache/1.3.27 (Unix)  (Red-Hat/Linux)
Last-Modified: Wed, 08 Jan 2003 23:11:55 GMT
Etag: "3f80f-1b6-3e1cb03b"
Accept-Ranges: bytes
Content-Length: 438
Connection: close
Content-Type: text/html; charset=UTF-8

Variação do GET em que o recurso não é retornado. É usado para obter metainformações por meio do cabeçalho da resposta, sem ter que recuperar todo o conteúdo.

Envia dados para serem processados (por exemplo, dados de um formulário HTML) para o recurso especificado. Os dados são incluídos no corpo do comando. Sua utilização em uma requisição ocorre quando é necessário enviar dados ao servidor para serem processados, geralmente por um programa script identificado no Request-URI. Uma requisição por meio desse método sempre requer que as informações submetidas sejam incluídas no corpo da mensagem e formatadas como uma query string, além de conter cabeçalhos adicionais especificando seu tamanho ( Content-Length) e seu formato ( Content-Type). Por isso, esse método oferece uma maior segurança em relação aos dados transferidos, ao contrário do método GET que os dados são anexados a URL, ficando visíveis ao usuário. Por exemplo:

 POST /index.html HTTP/1.0
 Accept: text/html
 If-modified-since: Sat, 29 Oct 1999 19:43:31 GMT
 Content-Type: application/x-www-form-urlencoded
 Content-Length: 41

 Nome=NomePessoa&Idade=99&Curso=Computacao

O método PUT envia os dados de forma semelhante ao POST, através do corpo do HTTP a diferença entre os 2 métodos é semântica. Por exemplo:

Caso você necessite atualizar os dados de um usuário, utilizando o método PUT você pode os atualizar diversas vezes, pois o PUT vai sobrescrever os dados com isso ficará somente com um único registro atualizado.

Se você executasse este mesmo procedimento utilizando o método POST, você criaria diversos registros para cada requisição realizada.

Exclui o recurso.

Ecoa o pedido, de maneira que o cliente possa saber o que os servidores intermediários estão mudando em seu pedido.

Recupera os métodos HTTP que o servidor aceita.

Serve para uso com um proxy que possa se tornar um túnel SSL e TLS (um túnel pode ser usado, por exemplo, para criar uma conexão segura).

Do HTTP/1.0 em diante, a primeira linha da resposta HTTP é chamada linha de estado e inclui um código de estado numérico (como " 404") e uma frase de razão textual (como "Not Found" - Não Encontrado). A maneira que o agente de usuário manipula a resposta depende primeiramente do código e secundariamente nos cabeçalhos de resposta. Códigos de estado personalizados podem ser usados, uma vez que, se o agente de usuário encontrar um código que ele não reconheça, ele pode usar o primeiro dígito do código para determinar a classe geral da resposta.

Da mesma forma, as frases de razão padrões são apenas recomendações e podem ser substituídas com "equivalentes locais" a critério do desenvolvedor web. Se o código de estado indicou um problema, o agente de usuário pode mostrar a frase de razão para o usuário, para que sejam fornecidas informações adicionais sobre a natureza do problema. O padrão também permite que o agente de usuário tente interpretar a frase de razão, apesar disto poder ser imprudente uma vez que o padrão especifica explicitamente que os códigos de estado são legíveis por máquina e as frases de razão são legíveis por homens.

No HTTP/0.9 e 1.0, a conexão é fechada após um único par de requisição/resposta. No HTTP/1.1 um mecanismo de persistência de vida (keep-alive) foi introduzido, onde uma conexão pode ser reutilizada para mais de uma requisição. Tais conexões persistentes reduzem a latência de requisição perceptível, pois o cliente não precisa renegociar a conexão TCP após a primeira requisição ter sido enviada. Outro efeito colateral positivo é que em geral a conexão se torna mais rápida com o tempo devido ao mecanismo de início-lento do TCP.

Para Fielding, uma mensagem de resposta do servidor é composta pelos seguintes campos: uma linha inicial ( Status-Line); linhas de cabeçalhos ( Responseheader); uma linha em branco obrigatória e um corpo de mensagem opcional. A linha inicial de uma resposta, chamada de linha de status, possui por sua vez três partes separadas por espaços: a versão do protocolo HTTP ( HTTP-Version), um código de status ( Status-Code) da resposta, que fornece o resultado da requisição, e uma frase de justificativa ( Reason-Phrase) que descreve o código do status.

A linha inicial de uma resposta HTTP indica ao cliente se sua requisição foi bem sucedida ou não. Essa situação é fornecida através de um código de retorno ( Status-Code) e uma frase explicativa ( Reason-Phrase). De acordo com Fielding, o código de status é formado por três dígitos e o primeiro dígito representa a classe que pertence classificada em cinco tipos:

1xx: Informational (Informação) - utilizada para enviar informações para o cliente de que sua requisição foi recebida e está sendo processada;

2xx: Success (Sucesso) - indica que a requisição do cliente foi bem sucedida;

3xx: Redirection (Redirecionamento) - informa a ação adicional que deve ser tomada para completar a requisição;

4xx: Client Error (Erro no cliente) - avisa que o cliente fez uma requisição que não pode ser atendida;

5xx: Server Error (Erro no servidor) - ocorreu um erro no servidor ao cumprir uma requisição válida.

O protocolo HTTP define somente alguns códigos em cada classe descritos na RFC 2616, mas cada servidor pode definir seus próprios códigos.

Segundo Hirata, o HTTP/1.0 é um protocolo sem estado. Isto significa que as conexões entre um cliente e um servidor são encerradas após o envio de cada requisição ou resposta. Cada vez que uma conexão é estabelecida ou encerrada, é consumida uma grande quantidade de tempo da CPU, de largura de banda e de memória.

Na maioria das vezes, para se obter o resultado esperado, é necessário realizar mais de uma solicitação de recursos através de várias conexões. Por exemplo, no caso de uma página Web, que consiste de diversos arquivos (.html, .gif, .css, etc.) é preciso que sejam feitas várias requisições para compor a página, uma conexão não-persistente. O ideal seria que apenas uma conexão fosse utilizada para os pedidos e as respostas HTTP, diminuindo, assim, a sobrecarga ocasionada pelas conexões, uma conexão persistente.

A conexão persistente, implementada como conexão padrão no protocolo HTTP/1.1, possibilita que uma conexão seja estabelecida para enviar várias requisições em seqüência sem a necessidade de esperar por cada resposta, no qual serão recebidas na mesma ordem em que as solicitações foram enviadas, um processo chamado de pipelining. Pode também dar-se o caso de ser estabelecida uma conexão sem pipelining, em que o cliente só faz nova requisição quando o servidor lhe envia a resposta, ou seja, o servidor fica inactivo até o objecto (.html, .gif, .css, etc) atingir o seu destino no cliente.

Se uma requisição incluir o cabeçalho Connection: close, a conexão será encerrada após o envio da resposta correspondente. Utiliza-se este cabeçalho quando não há suporte a conexões persistentes, quando for a última requisição a ser enviada nesta conexão, ou ainda, sempre que quiser encerrar a conexão mesmo que nem todas as requisições tenham sido completadas. Além disso, o servidor pode fechar uma conexão se estiver ociosa por um determinado período de tempo.

Pedido básico de HTTP cliente-servidor:

GET <ficheiro> HTTP/1.1
Host: <ip>
User-Agent: <Agente>
Connection: <tipo>

O agente é quem faz a ligação ao servidor, normalmente um navegador. O tipo indica como o servidor deve proceder com a conexão. É comumente utilizado para requisições persistentes.

Uma requisição completa pode exigir muitas informações. A requisição abaixo - utilizando o método POST - fora retirada do Mozilla Firefox v3.6b5 (pt-BR, para Windows):

POST /diretorio/arquivo.html HTTP/1.1
Host: www.exemplo.com
User-Agent: Mozilla/5.0 (Windows; U;Windows NT 6.1; pt-BR; rv:1.9.2b5) Gecko/20091204 Firefox/3.6b5 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: pt-br,pt;q=0.8,en-us;q=0.5,en;q=0.3 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-alive: 115 Cookie: nome=valor; nome2=valor2 Connection: keep-alive Content-Length: 28

usuario=exemplo&senha=123456

Referências

T. Berners-Lee, R. Fielding, H. Frystyk (maio de 1996). "Hypertext Transfer Protocol -- HTTP/1.0" (em inglês). Internet Engineering Task Force. Arquivado do original em 5 de maio de 2005

BASTOS, Leonara de Oliveira; LADEIRA, Adriane Cristina. Protocolo HTTP.

cf. 46 HERRMANN, Eric. Aprenda em 1 semana programação CGI em Perl 5. Rio de Janeiro: Campus, 1997

MACEDO, R. T. et al. Redes de computadores. 1. ed, 2018, Santa Maria, RS. p. 139.

# data[].attributes.attachment_link.title
Hypertext Transfer Protocol - Wikipédia, a enciclopédia livre

# data[].attributes.attachment_link.description
O Hypertext Transfer Protocol , sigla HTTP (em português Protocolo de Transferência de Hipertexto) é um protocolo de comunicação (na camada de aplicação segundo o Modelo OSI) utilizado para sistemas de informação de hipermídia, distribuídos e colaborativos. Ele é a base para a comunicação de dados da World Wide Web.

# data[].attributes.body
Um firewall é uma barreira de segurança que monitora e controla o tráfego de rede, permitindo ou bloqueando pacotes de dados com base em um conjunto predefinido de regras.

# data[].attributes.body
A criptografia de dados é uma técnica usada para proteger informações confidenciais, convertendo-as em um formato ininteligível para usuários não autorizados.

# data[].attributes.attachment_link.readable_text
Data encryption defined in Data Protection 101, our series on the fundamentals of data security.

What is Data Encryption?

Data encryption translates data into another form, or code, so that only people with access to a secret key (formally called a decryption key) or password can read it. Encrypted data is commonly referred to as ciphertext, while unencrypted data is called plaintext. Currently, encryption is one of the most popular and effective data security methods used by organizations. Two main types of data encryption exist - asymmetric encryption, also known as public-key encryption, and symmetric encryption.

The Primary Function of Data Encryption

The purpose of data encryption is to protect digital data confidentiality as it is stored on computer systems and transmitted using the internet or other computer networks. The outdated data encryption standard (DES) has been replaced by modern encryption algorithms that play a critical role in the security of IT systems and communications.

These algorithms provide confidentiality and drive key security initiatives including authentication, integrity, and non-repudiation. Authentication allows for the verification of a message's origin, and integrity provides proof that a message's contents have not changed since it was sent. Additionally, non-repudiation ensures that a message sender cannot deny sending the message.

How Does Encryption Work

Data, or plaintext, is encrypted with an encryption algorithm and an encryption key. The process results in ciphertext, which only can be viewed in its original form if it is decrypted with the correct key.

Types of encryption

Symmetric-key ciphers use the same secret key for encrypting and decrypting a message or file. While symmetric-key encryption is much faster than asymmetric encryption, the sender must exchange the encryption key with the recipient before he can decrypt it. As companies find themselves needing to securely distribute and manage huge quantities of keys, most data encryption services have adapted and use an asymmetric algorithm to exchange the secret key after using a symmetric algorithm to encrypt data.

On the other hand, asymmetric cryptography, sometimes referred to as public-key cryptography, uses two different keys, one public and one private. The public key, as it is named, may be shared with everyone, but the private key must be protected. The Rivest-Sharmir-Adleman (RSA) algorithm is a cryptosystem for public-key encryption that is widely used to secure sensitive data, especially when it is sent over an insecure network like the internet. The RSA algorithm's popularity comes from the fact that both the public and private keys can encrypt a message to assure the confidentiality, integrity, authenticity, and non-repudiability of electronic communications and data through the use of digital signatures.

Challenges to Contemporary Encryption

The most basic method of attack on encryption today is brute force, or trying random keys until the right one is found. Of course, the length of the key determines the possible number of keys and affects the plausibility of this type of attack. It is important to keep in mind that encryption strength is directly proportional to key size, but as the key size increases so do the number of resources required to perform the computation.

Alternative methods of breaking a cipher include side-channel attacks and cryptanalysis. Side-channel attacks go after the implementation of the cipher, rather than the actual cipher itself. These attacks tend to succeed if there is an error in system design or execution. Likewise, cryptanalysis means finding a weakness in the cipher and exploiting it. Cryptanalysis is more likely to occur when there is a flaw in the cipher itself.

Data Encryption Solutions

Data protection solutions for data encryption can provide encryption of devices, email, and data itself. In many cases, these encryption functionalities are also met with control capabilities for devices, email, and data. Companies and organizations face the challenge of protecting data and preventing data loss as employees use external devices, removable media, and web applications more often as a part of their daily business procedures. Sensitive data may no longer be under the company's control and protection as employees copy data to removable devices or upload it to the cloud. As a result, the best data loss prevention solutions prevent data theft and the introduction of malware from removable and external devices as well as web and cloud applications. In order to do so, they must also ensure that devices and applications are used properly and that data is secured by auto-encryption even after it leaves the organization.

As we mentioned, email control and encryption is another critical component of a data loss prevention solution. Secure, encrypted email is the only answer for regulatory compliance, a remote workforce, BYOD, and project outsourcing. Premier data loss prevention solutions allow your employees to continue to work and collaborate through email while the software and tools proactively tag, classify, and encrypt sensitive data in emails and attachments. The best data loss prevention solutions automatically warn, block, and encrypt sensitive information based on message content and context, such as user, data class, and recipient.

While data encryption may seem like a daunting, complicated process, data loss prevention software handles it reliably every day. Data encryption does not have to be something your organization tries to solve on its own. Choose a top data loss prevention software that offers data encryption with device, email, and application control and rest assured that your data is safe.

Tags: Data Protection 101

# data[].attributes.attachment_link.title
What Is Data Encryption? (Definition, Best Practices & More)

# data[].attributes.attachment_link.description
Data encryption defined in Data Protection 101, our series on the fundamentals of data security.

# data[].attributes.body
As Redes Virtuais Privadas (VPNs) são usadas para criar conexões seguras entre redes, protegendo a privacidade e a integridade dos dados transmitidos.

# data[].attributes.attachment_link.readable_text
Definição de VPN

VPN significa "Virtual Private Network" (Rede Privada Virtual) e descreve a oportunidade de estabelecer uma conexão de rede protegida ao usar redes públicas. As VPNs criptografam seu tráfego de Internet e disfarçam sua identidade online, sendo que essa criptografia ocorre em tempo real.

Isso torna mais difícil para terceiros rastrear suas atividades online e roubar seus dados.

Como funciona uma VPN?

Uma VPN oculta seu endereço IP deixando que a rede redirecione você por meio de um servidor remoto especialmente configurado executado por um host VPN.

Isso significa que se você navegar online com uma VPN, o servidor VPN se tornará a fonte de seus dados. Ou seja, seu Provedor de Serviços de Internet (ISP) e terceiros não podem ver quais sites você visita ou quais dados você envia e recebe online.

Uma VPN funciona como um filtro que transforma todos os seus dados em "rabiscos". Mesmo que alguém apreendesse esses dados, eles seriam inúteis.

Como uma boa VPN atua?

Você deve confiar em sua VPN para realizar uma ou mais tarefas. A VPN também deve ser ela mesma protegida contra comprometimentos. Estes são os recursos que você deve esperar de uma solução de VPN abrangente:

1. Criptografia do seu endereço IP: O trabalho principal de uma VPN é ocultar seu endereço IP de seu ISP e de terceiros. Isso permite enviar e receber informações online que só podem ser vistas por você e seu provedor VPN, mas sem risco de visualizações indesejadas.

2. Criptografia de protocolos: Uma VPN também deve impedir que você deixe rastros, por exemplo, na forma de histórico da internet, de pesquisa e cookies. A criptografia de cookies é especialmente importante porque evita que terceiros tenham acesso a informações confidenciais, como dados pessoais, informações financeiras e outros conteúdos de sites.

3. "Kill switch": Se sua conexão VPN for interrompida repentinamente, sua conexão segura também será interrompida. Uma boa VPN pode detectar esse tempo de inatividade repentino e encerrar os programas pré-selecionados, reduzindo a probabilidade de os dados serem comprometidos.

4. Autenticação de dois fatores: Usando uma variedade de métodos de autenticação, uma VPN forte verifica todos que tentam fazer login. Por exemplo, pode ser solicitado que você insira uma senha, e depois um código é enviado para seu dispositivo móvel. Isso dificulta o acesso de terceiros indesejados à sua conexão segura.

Quais são os benefícios de usar uma conexão VPN?

Uma conexão de Rede Privada Virtual disfarça seu tráfego de dados online e o protege de acesso externo. Os dados não criptografados podem ser vistos por qualquer pessoa que tenha acesso à rede e queira vê-los, porém com uma VPN, os hackers e criminosos cibernéticos não podem decifrar esses dados.

Isso é especialmente importante se você se conectar regularmente a redes Wi-Fi públicas.

Você nunca sabe quem pode estar monitorando seu tráfego de Internet e o que eles podem roubar de você, incluindo senhas, dados pessoais, informações de pagamento e toda sua identidade.

Conheça outras vantagens de ter uma VPN:

Criptografia segura

Para ler os dados, é preciso uma chave de criptografia. Sem uma, levaria milhões de anos para um computador decifrar o código no caso de um ataque de força bruta. Com a ajuda de uma VPN, suas atividades online ficam ocultas mesmo em redes públicas.

Disfarçando sua localização

Os servidores VPN atuam essencialmente como suas proxies na Internet. Como os dados de localização demográfica vêm de um servidor em outro país, sua localização real não pode ser determinada.

Além disso, a maioria dos serviços VPN não armazena registros de suas atividades. Alguns provedores, por outro lado, registram seu comportamento, mas não repassam essas informações a terceiros.

Isso significa que qualquer registro potencial do seu comportamento de usuário fica permanentemente oculto.

Acesso a conteúdo regional

O conteúdo regional da web nem sempre é acessível a partir de qualquer lugar. Os serviços e sites geralmente possuem conteúdo que só pode ser acessado em certas partes do mundo. Já as conexões padrão usam servidores locais no país para determinar sua localização.

Isso significa que você não pode acessar o conteúdo de sua casa durante uma viagem e não pode acessar o conteúdo internacional a partir de sua casa.

Com Spoofing de localização VPN, você pode mudar para um servidor de outro país e efetivamente "mudar" sua localização.

Transferência segura de dados

Se você trabalha remotamente, pode precisar acessar arquivos importantes na rede da sua empresa. Por razões de segurança, este tipo de informação requer uma conexão segura. Para obter acesso à rede, geralmente é necessária uma conexão VPN.

Os serviços de VPN se conectam a servidores privados e usam métodos de criptografia para reduzir o risco de vazamentos de dados.

Quais são os tipos principais de VPNs?

Existem muitos tipos diferentes de VPN, mas você definitivamente deve se familiarizar com os três tipos principais:

SSL VPN

Frequentemente, nem todos os funcionários de uma empresa têm acesso a um laptop da empresa que possam usar para trabalhar em casa. Durante a crise de COVID-19 em 2020, muitas empresas enfrentaram o problema de não terem equipamento suficiente para seus funcionários.

Nesses casos, muitas vezes recorre-se ao uso de um dispositivo privado (PC, laptop, tablet, celular). Neste caso, as empresas recorrem à solução de um SSL-VPN, que geralmente é implementada por meio de uma caixa de hardware correspondente.

Geralmente o pré-requisito é um navegador compatível com HTML-5, que é usado para acessar à página de login da empresa. Os navegadores compatíveis com HTML-5 estão disponíveis para praticamente qualquer sistema operacional. O acesso é protegido por um nome de usuário e senha.

VPN site a site

Uma VPN site a site é basicamente uma rede privada destinada a disfarçar intranets privadas, permitindo que os usuários dessas redes seguras acessem recursos mutuamente.

Esse tipo é útil se você tiver vários locais em sua empresa, cada um com sua própria rede local (LAN) conectada à WAN (Rede de Grande Extensão). VPNs de site a site também são úteis se você tiver duas intranets separadas entre as quais deseja enviar arquivos sem que os usuários de uma intranet acessem explicitamente à outra.

As VPNs site a site são usadas principalmente em empresas de grande porte. Eles são complexos de implementar e não oferecem a mesma flexibilidade que as VPNs SSL. No entanto, eles são a maneira mais eficaz de garantir a comunicação dentro e entre grandes departamentos.

VPN Cliente-a-Provedor

Conectando por meio de um Cliente VPN pode ser interpretado como se você estivesse conectando seu PC doméstico à empresa com um cabo de extensão.

Os funcionários podem discar para a rede da empresa a partir de seu escritório residencial por meio de uma conexão segura e agir como se estivessem no escritório. No entanto, um cliente VPN deve primeiro ser instalado e configurado no computador.

Isso envolve o usuário não estar conectado à Internet através do seu próprio ISP, mas estabelecer uma conexão direta através do seu provedor de VPN. Isso basicamente diminui a fase do túnel da jornada da VPN.

Assim, em vez de usar a VPN para criar um túnel de criptografia para disfarçar a conexão com a internet existente, a VPN pode criptografar automaticamente os dados antes de disponibilizá-los ao usuário.

Esta é uma forma cada vez mais comum de VPN, especialmente útil para provedores de Wi-Fi pública desprotegida WLAN. A solução impede que terceiros acessem e comprometam a conexão de rede e criptografa dados até o provedor.

Também impede que os ISPs acessem dados que, por qualquer motivo, permaneçam sem criptografia e contorna quaisquer restrições ao acesso do usuário à Internet (por exemplo, se o governo daquele país restringir o acesso à Internet).

A vantagem desse tipo de acesso VPN é uma maior eficiência e acesso universal aos recursos da empresa. Desde que um sistema telefônico apropriado esteja disponível, o funcionário pode, por exemplo, conectar-se ao sistema com um alto-falante e agir como se estivesse no local de trabalho da empresa.

Por exemplo, os clientes da empresa não conseguem nem saber se o funcionário está trabalhando no escritório ou em sua casa.

Como instalar uma VPN no computador?

Antes de instalar uma VPN, é importante se familiarizar com as diversas maneiras de implementá-las:

Cliente VPN

O software deve ser instalado para clientes VPN independentes. Esse software está configurado para corresponder aos requisitos do terminal. Ao configurar a VPN, o terminal executa o link de VPN e se conecta ao outro terminal, criando o túnel de criptografia.

Nas empresas, esta etapa geralmente requer a introdução de uma senha emitida pela empresa ou a instalação de um certificado apropriado. Ao usar uma senha ou certificado, o firewall pode reconhecer que esta é uma conexão autorizada.

O funcionário, então, se identifica por meio de credenciais de seu conhecimento.

Extensões para navegador

As extensões de VPN podem ser adicionadas à maioria dos navegadores da web, como Google Chrome e Firefox. Alguns navegadores, incluindo o Opera, possuem suas próprias extensões VPN integradas.

As extensões tornam mais fácil para os usuários alternar e configurar rapidamente sua VPN enquanto navegam na Internet. No entanto, a conexão VPN é válida apenas para as informações compartilhadas neste navegador.

O uso de outros navegadores e outras utilidades da Internet fora do navegador (por exemplo, jogos online) não podem ser criptografado pela VPN.

Embora as extensões do navegador não sejam tão abrangentes quanto os clientes VPN, elas podem ser uma opção apropriada para usuários ocasionais da Internet que desejam uma camada extra de segurança na Internet. No entanto, elas estão mais suscetíveis a violações.

Os usuários também são aconselhados a escolher uma extensão confiável, pois coletores de dados pode tentar usar extensões VPN falsas. A coleta de dados é a recolha de dados pessoais, como o que os estrategistas de marketing fazem para criar um perfil pessoal seu.

O conteúdo da publicidade é personalizado para você.

Roteador VPN

Se vários dispositivos estiverem conectados à mesma conexão de Internet, pode ser mais fácil implementar a VPN diretamente no roteador do que instalar uma VPN separada em cada dispositivo.

Um roteador VPN é especialmente útil se você deseja proteger dispositivos com conexão à Internet que não são fáceis de configurar, como TVs inteligentes. Eles podem até mesmo ajudar no acesso a conteúdo com restrição geográfica imposto por meio de seus sistemas de entretenimento doméstico.

Um roteador VPN é fácil de instalar, sempre fornece segurança e privacidade e evita que sua rede seja comprometida quando dispositivos inseguros se conectam. No entanto, pode ser mais difícil de gerenciar se seu roteador não tiver sua própria interface de usuário.

Isso pode fazer com que as conexões de entrada sejam bloqueadas.

VPN de Empresa

Uma VPN de empresa é uma solução personalizada que requer configuração e suporte técnico personalizados. A VPN geralmente é criada para você pela equipe de TI da empresa.

Como usuário, você não tem influência administrativa da VPN em si e suas atividades e transferências de dados são registradas por sua empresa. Isso permite que a empresa minimize o risco potencial de vazamento de dados.

A principal vantagem de uma VPN corporativa é uma conexão totalmente segura à intranet e ao servidor da empresa, mesmo para funcionários que trabalham fora da empresa usando sua própria conexão de internet.

Como instalar uma conexão VPN no smartphone

Como já mencionado, também existem conexões VPN para smartphones Android e iPhones. Felizmente, os serviços de VPN para smartphones são muito fáceis de usar e geralmente incluem o seguinte:

1. O processo de instalação geralmente baixa apenas um aplicativo da iOS App Store ou Google Play Store. Embora existam provedores de VPN gratuitos, é aconselhável escolher um provedor profissional quando se trata de segurança.

2. A configuração é extremamente simples, já que as configurações padrão já foram projetadas principalmente para o típico usuário de smartphone. Basta fazer login com sua conta. A maioria dos aplicativos irá guiá-lo através das principais funções dos serviços VPN.

3. Ativar a VPN é exatamente como qualquer botão liga/desliga para muitos aplicativos VPN. Você provavelmente encontrará a opção diretamente na tela inicial.

4. A troca de servidor geralmente é feita manualmente se você quiser alterar sua localização. Basta selecionar o país desejado a partir da oferta.

5. A configuração avançada está disponível para usuários que requerem um grau mais alto de proteção de dados. Dependendo da VPN, você pode também ser capaz de selecionar outros protocolos para o seu método de criptografia. Diagnósticos e outras funções também podem estar disponíveis no aplicativo. Antes de assinar, aprenda sobre esses recursos para encontrar a VPN certa para suas necessidades.

6. Para navegar na Internet com segurança a partir de agora, tudo o que você precisa fazer é primeiro ativar a conexão VPN através do aplicativo.

Mas tenha em mente o seguinte: Uma VPN é tão segura quanto o uso de dados e as políticas de armazenamento de seu provedor. Lembre-se que o serviço de VPN transfere seus dados para seus servidores e esses servidores se conectam à internet em seu nome.

Se eles armazenarem registros de dados, certifique-se de que está claro para que propósito esses registros são armazenados. Provedores de VPN sérios geralmente colocam sua privacidade em primeiro lugar. Você deve, portanto, escolher um provedor confiável, como o Kaspersky VPN Secure Connection.

Lembre-se apenas os dados da internet são criptografados. Qualquer coisa que não use uma conexão de celular ou Wi-Fi não será transmitida pela internet.

Como resultado, sua VPN não criptografará suas chamadas de voz ou textos padrão.

Uma VPN é mesmo segura?

É importante ter em conta que as VPNs não funcionam como um software antivírus abrangente. Embora protejam seu IP e criptografem seu histórico de internet, uma conexão VPN não protege seu computador de intrusões externas.

Para fazer isso, você definitivamente deve usar um software antivírus, como o Kaspersky Premium. Isso porque usar uma VPN por si só não o protege de cavalos de troia, bots ou outros malwares.

Depois do malware entrar no seu dispositivo, ele pode roubar ou danificar seus dados, esteja você executando uma VPN ou não. Portanto, é importante que você use uma VPN junto com um programa antivírus confiável para garantir segurança máxima.

Selecionando um provedor de VPN seguro

Também é importante escolher um provedor de VPN em que você possa confiar. Embora o seu ISP não possa ver o tráfego da Internet, o seu provedor de VPN pode. Se o seu provedor de VPN está comprometido, você também está.

Por esse motivo, é fundamental que você escolha um provedor de VPN confiável para garantir a ocultação de suas atividades na Internet e garantir o mais alto nível de segurança.

Navegando em segurança com uma VPN

VPNs diferentes usam processos de criptografia diferentes, mas geralmente funcionam em três passos:

1. Quando estiver online, inicie sua VPN. A VPN atua como um túnel seguro entre você e a Internet. Seu ISP e terceiros não conseguem detectar este túnel.

2. Seu dispositivo agora está na rede local da VPN e seu endereço IP pode ser alterado para um endereço IP fornecido pelo servidor VPN.

3. Agora você pode navegar na Internet à vontade, pois a VPN protege todos os seus dados pessoais.

A história das VPNs

Desde o início da internet, começaram a surgir formas de proteger e criptografar dados dos navegadores. O Departamento de Defesa dos Estados Unidos, por exemplo, começou a desenvolver projetos de criptografia de dados de comunicação da Internet ainda na década de 1960.

Entenda a seguir um pouco mais sobre como a conexão de Rede Privada Virtual surgiu:

Os predecessores da VPN

Esses esforços para proteção online levaram à criação da ARPANET (Rede da Agência de Projetos de Pesquisa Avançada), uma rede de comutação de pacotes, que por sua vez levou ao desenvolvimento do Protocolo de Controle de Transferência/Protocolo de Internet (TCP/IP).

O TCP/IP tinha quatro camadas: Link, internet, transporte e aplicativo. Ao nível da Internet, redes e dispositivos locais podem ser conectados à rede universal - e é aqui que o risco de exposição se torna claro.

Em 1993, uma equipe da Universidade da Columbia e da AT&T Bell Labs finalmente conseguiram criar uma espécie de primeira versão de VPN moderna, conhecida como swIPe: Protocolo de criptografia de IP de software.

No ano seguinte, Wei Xu desenvolveu a rede IPSec, um protocolo de segurança na internet que autentica e criptografa pacotes de informações compartilhados online. Em 1996, um funcionário da Microsoft chamado Gurdeep Singh-Pall criou um Protocolo de Túnel Peer-to-Peer (PPTP).

Primeiras VPNs

Em paralelo ao desenvolvimento do PPTP de Singh-Pall, a popularidade da Internet estava crescendo nos anos 1990. Com isso, surgiu a necessidade de ter sistemas de segurança sofisticados e prontos para o consumidor.

Naquela época, os programas antivírus já eram eficazes para impedir que malwares e spywares infectassem o sistema de um computador. No entanto, pessoas e empresas também começaram a exigir software de criptografia que pudesse ocultar seu histórico de navegação na internet.

As primeiras VPNs, portanto, começaram no início dos anos 2000, mas eram quase exclusivamente usadas por empresas.

No entanto, após uma enxurrada de violações de segurança, especialmente no início de 2010, o mercado consumidor de VPNs começou a crescer.

VPNs e seu uso atual

De acordo com GlobalWebIndex, o número de usuários de VPNs em todo o mundo aumentou mais de quatro vezes entre 2016 e 2018. Em países como Tailândia, Indonésia e China, onde o uso da internet é restrito e censurado, até um em cada cinco usuários de internet utilizam uma VPN.

Nos EUA, Grã-Bretanha e Alemanha, a proporção de usuários de VPNs é baixo com cerca de 5%, mas está crescendo. No Brasil, cerca de 1/3 da população conectada à internet utilizava VPN em 2023.

Um dos maiores impulsionadores da adoção de VPN nos últimos anos tem sido a crescente demanda dos usuários para acessar conteúdo com restrições geográficas de acesso. Por exemplo, serviços de streaming de vídeo, como o Netflix ou YouTube, tornam certos vídeos disponíveis apenas em alguns países.

Com as VPNs contemporâneas, você pode criptografar seu endereço IP para que pareça estar navegando de outro país, permitindo que você acesse esse conteúdo a partir de qualquer lugar.

Conclusão

Uma VPN estabelece uma conexão segura entre você e a Internet. Por meio dela, todo o tráfego de dados é roteado por um túnel virtual criptografado. Isso disfarça seu endereço IP quando você usa a internet, tornando sua localização invisível para todos.

Uma conexão VPN também é segura contra ataques externos. Isso porque apenas você pode acessar aos dados no túnel criptografado - e ninguém mais pode porque não tem a chave. Ela também permite que você acesse conteúdo com restrições regionais a partir de qualquer lugar do mundo.

Muitas plataformas de streaming não estão disponíveis em todos os países. Você ainda pode acessá-los usando a VPN. As soluções VPN da Kaspersky estão disponíveis para ambos PCs Windows e Apple Macs.

Existem agora também muitos provedores de conexões VPN para smartphones que mantêm o tráfego de dados móveis anônimo. Você pode encontrar fornecedores certificados na Google Play Store ou na iOS App Store.

Quais soluções de segurança incluem proteção VPN?

# data[].attributes.attachment_link.description
Uma VPN criptografa e torna anônimo seu tráfego de dados online. Mas quão segura é uma conexão VPN e como você a configura?