
English: 
Hi, I’m Carrie Anne, and welcome to CrashCourse
Computer Science!
As we talked about last episode, your computer
is connected to a large, distributed network,
called The Internet.
I know this because you’re watching a youtube
video, which is being streamed over that very
internet.
It’s arranged as an ever-enlarging web of
interconnected devices.
For your computer to get this video, the first
connection is to your local area network,
or LAN, which might be every device in your
house that’s connected to your wifi router.
This then connects to a Wide Area Network,
or WAN, which is likely to be a router run
by your Internet Service Provider, or ISP
– companies like Comcast, AT&T or Verizon.
At first, this will be a regional router,
like one for your neighborhood, and then that
router connects to an even bigger WAN, maybe
one for your whole city or town.
There might be a couple more hops, but ultimately
you’ll connect to the backbone of the internet
made up of gigantic routers with super high-bandwidth
connections running between them.
To request this video file from youtube, a
packet had to work its way up to the backbone,

Korean: 
안녕하세요, Carrie Anne입니다.
컴퓨터 과학 특강에 오신 것을 환영합니다!
지난시간에 얘기했든이, 여러분의 컴퓨터는 인터넷
이라는 대규모의 분산 네트워크에 연결되어 있습니다.
지난시간에 얘기했든이, 여러분의 컴퓨터는 인터넷
이라는 대규모의 분산 네트워크에 연결되어 있습니다.
여러분이 인터넷을 통해 스트리밍 되는 유튜브 동영상을
보고 있다는 걸 저는 알고 있습니다.
여러분이 인터넷을 통해 스트리밍 되는 유튜브 동영상을
보고 있다는 걸 저는 알고 있습니다.
상호 연결된 장치의 웹이 계속 확대되어 배치됩니다.
컴퓨터에서 이 비디오를 얻으려면 가장 먼저
로컬 영역 네트워크로(또는 LAN) 연결합니다.
아마 집안의  Wi-Fi 라우터에 연결된 모든 기기가
 LAN에 연결되어 있을 수 있습니다.
그런 다음 광대역 네트워크(WAN)에 연결합니다. 
그 라우터는 ISP (인터넷 서비스 제공 업체) 또는 ISP
Comcast, AT & T, Verizon과 같은 회사가 운영하는 것일 수 있습니다.(한국의 경우 KT, SKT, LG와 같음)
처음에는 이웃과 연결하는 지역 라우터가 될 것이고,
그리고 라우터는 전체 도시 또는 마을을 위한 
더 큰 WAN에 연결될 것입니다.
두 개 이상의 홉이 있을 수 있지만 궁극적으로는
인터넷의 백본에 연결합니다.
백본은 그들 사이에서 실행되는 초고 대역폭의
연결을 가진 거대한 라우터로 구성됩니다.
YouTube에서 이 비디오 파일을 요청하려면 
백본까지 패킷을 보내고

English: 
travel along that for a bit, and then work
its way back down to a youtube server that
had the file.
That might be four hops up, two hops across
the backbone, and four hops down, for a total
of ten hops.
If you’re running Windows, MacOS or Linux,
you can see the route data takes to different
places on the internet by using the traceroute
program on your computer.
Instructions in the Doobly Doo.
For us here at the Chad & Stacey Emigholz
Studio in Indianapolis, the route to the DFTBA
server in California goes through 11 stops.
We start at 192.168.0.1 -- thats the IP address
for my computer on our LAN.
Then there’s the wifi router here at the
studio, then a series of regional routers,
then we get onto the backbone, and then we
start working back down to the computer hosting
“DFTBA dot com”, which has the IP address
104.24.109.186.
But how does a packet actually get there?
What happens if a packet gets lost along the
way?
If I type “DFTBA dot com” into my web
browser, how does it know the server’s address?
Those are our topics for today!

Korean: 
조금 이동 한 다음 파일이있는 
YouTube 서버로 돌아가야 했습니다.
조금 이동 한 다음 파일이있는 
YouTube 서버로 돌아가야 했습니다.
이것은 4홉을 올라가서, 백본까지 2홉,
다시 내려오는 데에 4홉, 총 10 홉이 될 수 있습니다.
이것은 4홉을 올라가서, 백본까지 2홉,
다시 내려오는 데에 4홉, 총 10홉이 될 수 있습니다.
여러분이 Windows, MacOS 또는 Linux를 사용하는 경우,
컴퓨터의 traceroute 프로그램을 사용하여 인터넷의 
다른 위치로 데이터가 이동하는 경로를 볼 수 있습니다
대부분의 YouTube 동영상에 대한 설명 섹션처럼요.
우리의 경우 여기 인디애나 폴리스의 Chad & Stacey 
Emigholz 스튜디오에서 캘리포니아의 DFTBA 서버까지
11 정거장을 지나갑니다.
192.168.0.1부터 시작합니다. 
이는 우리의 LAN에 있는 내 컴퓨터의 IP 주소입니다.
그런 다음 여기에 일련의 지역 라우터인
스튜디오 wifi 라우터가 있습니다.
그런 다음 우리는 백본으로 올라가고
IP 주소가 104.24.109.186 인
"DFTBA dot com"을 호스팅하는 컴퓨터로 
다시 작업을 시작합니다.
그러나 패킷이 실제로 거기에 어떻게 도달할까요?
패킷이 가는 도중 손실되면 어떻게 될까요?
내 웹에 "DFTBA.com"을 입력하면
브라우저에서 서버의 주소를 어떻게 알 수 있을까요?
그것들이 오늘 우리의 주제입니다!

Korean: 
 
지난 강의에서 논했듯, 인터넷은 데이터를 작은 패킷으로
보내는 거대한 분산 네트워크입니다.
지난 강의에서 논했듯, 인터넷은 데이터를 작은 패킷으로
보내는 거대한 분산 네트워크입니다.
데이터가 이메일의 첨부파일처럼 충분히 크면
여러 개의 패킷으로 나눌 수 있습니다.
데이터가 이메일의 첨부파일처럼 충분히 크면
여러 개의 패킷으로 나눌 수 있습니다.
예를 들어, 이 비디오 스트림이 지금 연속적인 패킷들로 
도착 중입니다.
하나의 거대한 파일로 오지 않습니다.
인터넷 패킷은 IP (Internet Protocol) 또는 IP라고 하는 
표준을 준수해야 합니다.
우편 시스템을 통해 실제 메일을 보내는 것과
원리는 같습니다.
모든 메일에는 독창적이고 읽기 쉬운 주소가 적혀있고, 
소포의 크기와 무게에는 한계가 있습니다.
모든 메일에는 독창적이고 읽기 쉬운 주소가 적혀있고, 
소포의 크기와 무게에는 한계가 있습니다.
이를 위반하면 편지는 통과되지 않습니다.
IP 패킷은 이와 매우 유사합니다.
그러나 IP는 매우 낮은 수준의 프로토콜입니다. 
패킷의 헤더에 목적지 주소가 그다지 많지 않습니다.
데이터 페이로드 앞에 저장된 메타데이터를
패킷의 헤더라고 합니다.
즉, 패킷이 컴퓨터에 표시될 수 있지만 컴퓨터는 
데이터를 제공할 응용 프로그램을 알지 못할 수 있습니다.
Skype 인지, Call of Duty인지.

English: 
INTRO
As we discussed last episode, the internet
is a huge distributed network that sends data
around as little packets.
If your data is big enough, like an email
attachment, it might get broken up into many
packets.
For example, this video stream is arriving
to your computer right now as a series of
packets, and not one gigantic file.
Internet packets have to conform to a standard
called the Internet Protocol, or IP.
It’s a lot like sending physical mail through
the postal system – every letter needs a
unique and legible address written on it,
and there are limits to the size and weight
of packages.
Violate this, and your letter won’t get
through.
IP packets are very similar.
However, IP is a very low level protocol – there
isn’t much more than a destination address
in a packet’s header, which is the metadata
that’s stored in front of the data payload.
This means that a packet can show up at a
computer, but the computer may not know which
application to give the data to; Skype or
Call of Duty.

Korean: 
이런 이유로, 더 진보한 프로토콜은
IP의 최상위에 개발되었습니다.
가장 단순하고 가장 일반적인 것 중 하나는
사용자 데이터그램 프로토콜 또는 UDP라고 부릅니다.
UDP는 내부에 데이터 페이로드 자체 헤더가 있습니다.
UDP 헤더의 내부는 유용한, 추가적인 정보가 있습니다.
그 중 하나가 포트 번호입니다.
인터넷에 접속하려는 모든 프로그램은 호스트 컴퓨터의
운영 체제에 고유한 포트가 제공되도록 요청합니다.
인터넷에 접속하려는 모든 프로그램은 호스트 컴퓨터의
운영 체제에 고유한 포트가 제공되도록 요청합니다.
예를 들어 Skype는 포트 번호 
3478을 요구할 수 있습니다.
패킷이 컴퓨터에 도착하면 운영 체제는 
UDP 헤더 내부를 보고 포트 번호를 읽습니다.
패킷이 컴퓨터에 도착하면 운영 체제는 
UDP 헤더 내부를 보고 포트 번호를 읽습니다.
그런 다음, 예를 들어 3478이 표시되면
Skype로 패킷을 보냅니다.
따라서 검토를 위해, IP는 올바른 컴퓨터로 패킷을 가져 오지만
UDP는 해당 컴퓨터에서 실행중인
올바른 프로그램으로 패킷을 가져옵니다.
또한 UDP헤더에는 체크섬이라는 데이터가 포함되있어
데이터의 정확성을 확인할 수 있습니다.
또한 UDP헤더에는 체크섬이라는 데이터가 포함되있어
데이터의 정확성을 확인할 수 있습니다.
이름에서 알 수 있듯, 
체크섬은 데이터의 합계를 확인합니다.
다음은 이 방법의 단순화 된 버전입니다.
UDP 패킷의 원시 데이터를
89, 111, 33, 32, 58 및 41이라고 가정해 봅시다.

English: 
For this reason, more advanced protocols were
developed that sit on top of IP.
One of the simplest and most common is the
User Datagram Protocol, or UDP.
UDP has its own header, which sits inside
the data payload.
Inside of the UDP header is some useful, extra
information.
One of them is a port number.
Every program wanting to access the internet
will ask its host computer’s Operating System
to be given a unique port.
Like Skype might ask for port number 3478.
When a packet arrives to the computer, the
Operating System will look inside the UDP
header and read the port number.
Then, if it sees, for example, 3478, it will
give the packet to Skype.
So to review, IP gets the packet to the right
computer, but UDP gets the packet to the right
program running on that computer.
UDP headers also include something called
a checksum, which allows the data to be verified
for correctness.
As the name suggests, it does this by checking
the sum of the data.
Here’s a simplified version of how this
works.
Lets imagine the raw data in our UDP packet
is 89 111 33 32 58 and 41.

English: 
Before the packet is sent, the transmitting
computer calculates the checksum by adding
all the data together: 89 plus 111 plus 33
and so on.
In our example, this adds up to a checksum
of 364.
In UDP, the checksum value is stored in 16
bits.
If the sum exceeds the maximum possible value,
the upper-most bits overflow, and only the
lower bits are used.
Now, when the receiving computer gets this
packet, it repeats the process, adding up
all the data.
89 plus 111 plus 33 and so on.
If that sum is the same as the checksum sent
in the header, all is well.
But, if the numbers don’t match, you know
that the data got corrupted at some point
in transit, maybe because of a power fluctuation
or faulty cable.
Unfortunately, UDP doesn’t offer any mechanisms
to fix the data, or request a new copy – receiving
programs are alerted to the corruption, but
typically just discard the packet.
Also, UDP provides no mechanisms to know if
packets are getting through – a sending
computer shoots the UDP packet off, but has
no confirmation it ever gets to its destination
successfully.

Korean: 
패킷이 전송되기 전에, 전송하는 컴퓨터는 
모든 데이터를 더해서 체크섬을 계산합니다.
89 + 111 + 33 + ...등등.
이 예에서는 모두 더한 값인 364가 체크섬입니다.
UDP에서는 체크섬 값이 16비트로 저장됩니다.
합계가 가능한 최대값을 초과하는 경우,
최상위 비트가 오버플로되고 하위 비트만 사용됩니다.
합계가 가능한 최대값을 초과하는 경우,
최상위 비트가 오버플로되고 하위 비트만 사용됩니다.
이제 수신하는 컴퓨터에서 이 패킷을 받으면, 
모든 데이터를 더하는 과정을 반복합니다.
이제 수신하는 컴퓨터에서 이 패킷을 받으면, 
모든 데이터를 더하는 과정을 반복합니다.
89 + 111 + 33 등등.
그 합계가 전송된 헤더로 보내진 체크섬과 같은 경우
모두 잘 된것입니다.
그러나 숫자가 일치하지 않으면 어떤 전송 시점에서 
데이터가 손상되었다는 것을 알 수 있습니다.
혹은 전원 변동이나 케이블 결함일 수 있습니다.
유감스럽게도, UDP는 데이터를 수정하거나 새 복사본을 
요청하는 어떤 메커니즘도 제공하지 않습니다.
수신 프로그램은 손상에 대해 경고를 받지만
일반적으로 패킷을 폐기합니다.
또한, UDP는 패킷의 통과 여부를 알 수 있는 
메커니즘이 없습니다.
송신 컴퓨터가 UDP 패킷을 쏘지만 목적지에
성공적으로 도달하는지 확인하지는 않습니다.
송신 컴퓨터가 UDP 패킷을 쏘지만 목적지에
성공적으로 도달하는지 확인하지는 않습니다.

Korean: 
이 두 속성은 꽤 비극적인 것처럼 들리지만,
일부 응용 프로그램은 이것으로 괜찮습니다.
왜냐하면 UDP는 정말 간단하고 빠르기 때문입니다.
예를 들어 비디오챗 용으로 UDP를 사용하는 Skype는
채팅, 손상되거나 누락된 패킷을 처리 할 수 ​​있습니다.
그렇기 때문에 때때로 인터넷 연결 상태가 좋지 않은 경우
Skype가 모든 오류를 일으키며 
일부 UDP 패킷만 컴퓨터로 전달됩니다.
Skype가 모든 오류를 일으키며 
일부 UDP 패킷만 컴퓨터로 전달됩니다.
그러나 이 방법은 다른 많은 유형의 
데이터 전송에는 효율적이지 않습니다.
마치, 여러분이 메일을 보냈는데 중간을 
빠뜨린 채로 나타나는 상황과 같이요.
마치, 여러분이 메일을 보냈는데 중간을 
빠뜨린 채로 나타나는 상황과 같이요.
전체 메시지가 목적지에 정확하게 도착해야합니다.
"절대적으로, 적극적으로 거기에 도달해야" 할 때, 
프로그램은 전송 제어 프로토콜(TCP)을 사용합니다.
이는 UDP처럼,
안에  IP 패킷의 데이터 페이로드가 있습니다.
이러한 이유로 사람들은 이 프로토콜 조합
TCP / IP라고합니다.
UDP와 마찬가지로, TCP 헤더에는
대상 포트 및 체크섬이 포함됩니다.
그러나 이 제품에는 더 멋진 기능이 포함되어 있습니다.
우리는 중요한 것에 집중해 살펴보겠습니다.
첫째로, TCP 패킷은 일련 번호가 부여됩니다.
따라서 패킷 15 다음에 패킷 16이 이어지며,
그 다음에 17, 계속해서 ..
어쩌면 그 세션 동안 전송된,
수백만 개의 패킷이 계속됩니다.

English: 
Both of these properties sound pretty catastrophic,
but some applications are ok with this, because
UDP is also really simple and fast.
Skype, for example, which uses UDP for video
chat, can handle corrupt or missing packets.
That’s why sometimes if you’re on a bad
internet connection,
Skype gets all glitchy – only some of the
UDP packets are making it to your computer.
Skype does the best it can with the data it
does receive correctly.
But this approach doesn’t work for many
other types of data transmission.
Like, it doesn’t really work if you send
an email, and it shows up with the middle
missing.
The whole message really needs to get there
correctly!
When it “absolutely, positively needs to
get there”, programs use the Transmission
Control Protocol, or TCP, which like UDP,
rides inside the data payload of IP packets.
For this reason, people refer to this combination
of protocols as TCP/IP.
Like UDP, the TCP header contains a destination
port and checksum.
But, it also contains fancier features, and
we’ll focus on the key ones.
First off, TCP packets are given sequential
numbers.
So packet 15 is followed by packet 16, which
is followed by 17, and so on... for potentially
millions of packets sent during that session.

Korean: 
이러한 일련 번호는 수신 컴퓨터가
올바른 순서로 패킷을 넣도록 합니다.
그들이 네트워크를 건너
서로 다른 시간에 도착할지라도요.
따라서 전자 메일이 모두 섞이면, 컴퓨터 운영 체제의
TCP 구현이 이 모든 것을 올바르게 결합합니다.
따라서 전자 메일이 모두 섞이면, 컴퓨터 운영 체제의
TCP 구현이 이 모든 것을 올바르게 결합합니다.
둘째, TCP는 컴퓨터가 패킷을 올바르게 수신하고 
데이터가 체크섬을 통과하면
확인 메시지를 보내거나, 흔히 Cool kid들이 말하는 
"ACK"를 발신 컴퓨터에 보내야 합니다.
확인 메시지를 보내거나, 흔히 Cool kid들이 말하는 
"ACK"를 발신 컴퓨터에 보내야 합니다.
패킷이 성공적으로 전송되었음을 알면,
보낸 사람은 이제 다음 패킷을 전송할 수 있습니다.
그러나 이번에는 ACK를 받지 않고
기다리고 있다고 가정해 봅시다.
뭔가 잘못되었습니다. 충분한 시간이 경과하면,
발신자는 앞으로 가서 동일한 패킷을 재전송합니다.
뭔가 잘못되었습니다. 충분한 시간이 경과하면,
발신자는 앞으로 가서 동일한 패킷을 재전송합니다.
원래 패킷이 실제로 거기에 도착했을 수도 있더라도
소용이 없습니다.
답신은 정말로 지연됩니다.
아니면 아마도 답신이 길을 잃었을 것입니다.
어느 쪽이든 그것은 중요하지 않습니다.
왜냐하면 수신기는 그 일련 번호를 가지며,
만약 중복 패킷이 도착하면 이를 버릴 수 있습니다.
또한 TCP는 앞뒤로 대화하는 것에 국한되지 않습니다. 
많은 패킷을 보낼 수 있으며
ACK가 반환되길 기다리는 시간을 낭비하지 않으므로 
대역폭을 크게 늘리는 많은 미해결 ACK가 있습니다.

English: 
These sequence numbers allow a receiving computer
to put the packets into the correct order,
even if they arrive at different times across
the network.
So if an email comes in all scrambled, the
TCP implementation in your computer’s operating
system will piece it all together correctly.
Second, TCP requires that once a computer
has correctly received a packet – and the
data passes the checksum – that it send
back an acknowledgement, or “ACK” as the
cool kids say, to the sending computer.
Knowing the packet made it successfully, the
sender can now transmit the next packet.
But this time, let’s say, it waits, and
doesn’t get an acknowledgement packet back.
Something must be wrong If enough time elapses,
the sender will go ahead and just retransmit
the same packet.
It’s worth noting that the original packet
might have actually gotten there, but the
acknowledgment is just really delayed.
Or perhaps it was the acknowledgment that
was lost.
Either way, it doesn’t matter, because the
receiver has those sequence numbers, and if
a duplicate packet arrives, it can be discarded.
Also, TCP isn’t limited to a back and forth
conversation – it can send many packets,
and have many outstanding ACKs, which increases
bandwidth significantly, since you aren’t

English: 
wasting time waiting for acknowledgment packets
to return.
Interestingly, the success rate of ACKs, and
also the round trip time between sending and
acknowledging, can be used to infer network
congestion.
TCP uses this information to adjust how aggressively
it sends packets – a mechanism for congestion
control.
So, basically, TCP can handle out-of-order
packet delivery, dropped packets – including
retransmission – and even throttle its transmission
rate according to available bandwidth.
Pretty awesome!
You might wonder why anyone would use UDP
when TCP has all these nifty features.
The single biggest downside are all those
acknowledgment packets – it doubles the
number of messages on the network, and yet,
you're not transmitting any more data.
That overhead, including associated delays,
is sometimes not worth the improved robustness,
especially for time-critical applications,
like Multiplayer First Person Shooters.
And if it’s you getting lag-fragged you’ll
definitely agree!
When your computer wants to make a connection
to a website, you need two things - an IP
address and a port.

Korean: 
ACK가 반환되길 기다리는 시간을 낭비하지 않으므로 
대역폭을 크게 늘리는 많은 미해결 ACK가 있습니다.
흥미롭게도, ACK 성공률과 전송 및 수신 확인 간의 
왕복시간은 네트워크 정체를 추정하는 데 사용할 수 있습니다.
흥미롭게도, ACK 성공률과 전송 및 수신 확인 간의 
왕복시간은 네트워크 정체를 추정하는 데 사용할 수 있습니다.
TCP는이 정보를 사용하여 패킷을 얼마나 적극적으로 
전송 하는지를 조정합니다 - 정체 제어를 위한 메커니즘
TCP는이 정보를 사용하여 패킷을 얼마나 적극적으로 
전송 하는지를 조정합니다 - 정체 제어를 위한 메커니즘
따라서 기본적으로 TCP는 순서가 잘못된 패킷 전달,
 삭제된 패킷 -재전송을 포함하여- 처리할 수 있으며
심지어 사용 가능한 대역폭에 따라
전송 속도를 조절할 수도 있습니다.
꽤 멋지죠!
TCP가 이러한 멋진 기능들을 모두 가지고 있을 때
굳이 UDP를 써야 하는지 궁금해 할 수 있습니다.
가장 큰 단점은 수신 확인 패킷입니다.
네트워크에서 메시지 수가 두 배로 증가하지만
 더 이상 데이터를 전송하지 않습니다.
관련 지연을 포함하는 그 오버 헤드는,
때로는 견고성을 향상시킬 만한 가치가 없습니다.
특히 멀티 플레이어 1인칭 슈팅 게임과 같이
시간이 중요한 응용 프로그램의 경우에요.
그리고 여러분이 지체에 빠진다면 
분명히 동의할 겁니다.
컴퓨터로 웹사이트에 연결하고 싶으면
IP주소와 포트가 필요합니다.
컴퓨터로 웹사이트에 연결하고 싶으면
IP주소와 포트가 필요합니다.

Korean: 
포트 80 
IP주소 172.217.7.238 처럼요.
이 예제는 Google 웹 서버의 IP 주소와 포트입니다
사실, 이것을 주소 표시 줄에 브라우저에 입력하면, 
구글 홈페이지가 표시될 것입니다.
사실, 이것을 주소 표시 줄에 브라우저에 입력하면, 
구글 홈페이지가 표시될 것입니다.
이것은 여러분을 옳은 목적지에 데려다 주지만,
그 긴 문자열을 기억하는것은 꽤 귀찮습니다.
이것은 여러분을 옳은 목적지에 데려다 주지만,
그 긴 문자열을 기억하는것은 꽤 귀찮습니다.
google.com을 기억하는 것이 훨씬 쉽습니다.
그래서 인터넷에는 도메인 이름을 주소에 매핑하는
특별한 서비스가 있습니다.
이는 인터넷 전화 번호부와 같습니다.
도메인 네임 시스템 (Domain Name System)
또는 짧게 DNS라고 합니다.
여러분은 아마 어떻게 작동하는지 짐작할 수 있습니다.
웹 브라우저에 "youtube.com"과 같은 것을 입력하면
ISP가 제공하는 DNS 서버에 가서 
주소를 조회하도록 요청합니다.
DNS는 거대한 레지스트리를 참조하고 주소가있는 경우
주소로 응답합니다.
실제로 브라우저에서 키보드를 아무렇게나 두들겨
".com"을 추가 한 다음  Enter 키를 누르면
DNS가 실패했다는 오류가 표시됩니다.
왜냐하면 이 사이트는 존재하지 않기 때문에,
따라서 DNS가 브라우저에 주소를 제공 할 수 없습니다.
그러나 DNS가 "youtube.com"에 대해 유효한 주소를 반환하면,

English: 
Like port 80, at 172.217.7.238.
This example is the IP address and port for
the Google web server.
In fact, you can enter this into your browser’s
address bar, like so, and you’ll end up
on the google homepage.
This gets you to the right destination, but
remembering that long string of digits would
be really annoying.
It’s much easier to remember: google.com.
So the internet has a special service that
maps these domain names to addresses.
It’s like the phone book for the internet.
And it’s called the Domain Name System,
or DNS for short.
You can probably guess how it works.
When you type something like “youtube.com”
into your web browser, it goes and asks a
DNS server – usually one provided by your
ISP – to lookup the address.
DNS consults its huge registry, and replies
with the address... if one exists.
In fact, if you try mashing your keyboard,
adding “.com”, and then hit enter in your
browser, you’ll likely be presented with
an error that says DNS failed.
That’s because that site doesn’t exist,
so DNS couldn’t give your browser an address.
But, if DNS returns a valid address, which
it should for “youtube.com”, then your

Korean: 
브라우저가 TCP를 통해 웹 사이트의 데이터 요청을 실행합니다.
등록 된 도메인 이름이 3억 개가 넘기 때문에
 DNS 조회를 관리하기 쉽도록
하나의 큰 목록으로 저장하지 않고
트리 데이터 구조로 저장합니다.
하나의 큰 목록으로 저장하지 않고
트리 데이터 구조로 저장합니다.
최상위 도메인 또는 TLD라고 하는 것이 맨 위에 있습니다.
이들은 .com과 .gov 와 같은 거대한 카테고리입니다.
그런 다음 두 번째 수준 도메인이라고 하는 
하위 도메인이 있습니다.
예시로, .com 아래에 google.com, dftba.com가 있습니다.
그런 다음 하위 도메인이라는 더 낮은 수준의 도메인
 (예 : images.google.com, store.dftba.com.)이 있습니다.
그런 다음 하위 도메인이라는 더 낮은 수준의 도메인
 (예 : images.google.com, store.dftba.com.)이 있습니다.
그리고 이 나무는 절대적으로 거대합니다!
앞서 말했듯이, 3억 개 이상의 도메인 이름은 모든 하위 
도메인이 아니라 단지 두 번째 레벨 도메인 이름입니다.
앞서 말했듯이, 3억 개 이상의 도메인 이름은 모든 하위 
도메인이 아니라 단지 두 번째 레벨 도메인 이름입니다.
이러한 이유로, 이 데이터는 트리의 다른 부분에 
대한 권한인 많은 DNS 서버에 분산됩니다.
이러한 이유로, 이 데이터는 트리의 다른 부분에 
대한 권한인 많은 DNS 서버에 분산됩니다.
네, 여러분이 기다리고 있는 걸 압니다.
새로운 차원의 추상화에 도달했습니다!

English: 
browser shoots off a request over TCP for
the website’s data.
There’s over 300 million registered domain
names, so to make that DNS Lookup a little
more manageable, it’s not stored as one
gigantically long list, but rather in a tree
data structure.
What are called Top Level Domains, or TLDs,
are at the very top.
These are huge categories like .com and .gov.
Then, there are lower level domains that sit
below that, called second level domains; Examples
under .com include google.com and
dftba.com.
Then, there are even lower level domains,
called subdomains, like images.google.com,
store.dftba.com.
And this tree is absolutely HUGE!
Like I said, more than 300 million domain
names, and that's just second level domain
names, not all the sub domains.
For this reason, this data is distributed
across many DNS servers, which are authorities
for different parts of the tree.
Okay, I know you’ve been waiting for it...
We’ve reached a new level of abstraction!

Korean: 
지난 두 편의 강의에서, 우리는 무선 네트워크의 경우 
전선의 전기 신호와
또는 공중을 통해 전송되는 무선 신호를 처리했습니다.
이를 물리적 계층이라고 합니다.
MAC 주소, 충돌 감지, 지수 백 오프 및 물리 계층에 대한 접근을 중재하는 유사한 저급 프로토콜은
데이터 링크 계층의 일부입니다.
위의 네트워크 레이어는 우리가 논의한 모든 스위칭 및 
라우팅 기술이 작동하는 곳입니다.
위의 네트워크 레이어는 우리가 논의한 모든 스위칭 및 
라우팅 기술이 작동하는 곳입니다.
그리고 오늘 우리는 전송 계층을 주로 다루었는데, 
UDP와 TCP 같은 프로토콜은
컴퓨터 간의 지점 간 데이터 전송을 책임지고 가능한
 경우 오류 검색 및 복구와 같은 작업도 담당합니다.
컴퓨터 간의 지점 간 데이터 전송을 책임지고 가능한
 경우 오류 검색 및 복구와 같은 작업도 담당합니다.
우리는 또한 Session Layer를 스쳐 왔습니다.
TCP 및 UDP와 같은 프로토콜을 사용하여
연결을 열고 앞뒤로 정보를 전달한 다음
작업이 완료되면 연결을 닫습니다.
- 이것을 세션이라고 합니다.
이것은 정확히 여러분이 DNS를 찾거나, 
웹페이지를 요청할 때 일어나는 일입니다.
이것들은 OSI (Open System Interconnection)모델의
하위 5개 층이며,
이 모든 다른 네트워크 프로세스를 구획화 하기 위한
개념적 뼈대입니다.
각 단계마다 걱정할 문제와 해결할 것이 많아서, 하나의 거대한 네트워킹 구현을 구축하는 것은 불가능합니다.

English: 
Over the past two episodes, we’ve worked
up from electrical signals on wires, or radio
signals transmitted through the air in the
case of wireless networks.
This is called the Physical Layer.
MAC addresses, collision detection, exponential
backoff and similar low level protocols that
mediate access to the physical layer are part
of the Data Link Layer.
Above this is the Network Layer, which is
where all the switching and routing technologies
that we discussed operate.
And today, we mostly covered the Transport
layer, protocols like UDP and TCP, which are
responsible for point to point data transfer
between computers, and also things like error
detection and recovery when possible.
We’ve also grazed the Session Layer – where
protocols like TCP and UDP are used to open
a connection, pass information back and forth,
and then close the connection when finished
– what’s called a session.
This is exactly what happens when you, for
example, do a DNS Lookup, or request a webpage.
These are the bottom five layers of the Open
System Interconnection (OSI) model, a conceptual
framework for compartmentalizing all these
different network processes.
Each level has different things to worry about
and solve, and it would be impossible to build

English: 
one huge networking implementation.
As we’ve talked about all series, abstraction
allows computer scientists and engineers to
be improving all these different levels of
the stack simultaneously, without being overwhelmed
by the full complexity.
And amazingly, we’re not quite done yet…
The OSI model has two more layers, the Presentation
Layer and the Application Layer, which include
things like web browsers, Skype, HTML decoding,
streaming movies and more.
Which we’ll talk about next week.
See you then.

Korean: 
각 단계마다 걱정할 문제와 해결할 것이 많아서, 하나의 거대한 네트워킹 구현을 구축하는 것은 불가능합니다.
우리가 모든 강의에서 말했듯이, 
컴퓨터 과학자와 엔지니어는 추상화를 통해
복잡성에 완전히 압도 당하지 않고 이러한 다양한 수준의
 스택을 동시에 향상시킬 수 있습니다.
복잡성에 완전히 압도 당하지 않고 이러한 다양한 수준의
 스택을 동시에 향상시킬 수 있습니다.
놀랍게도, 아직 완성되지 않았습니다.
OSI 모델에는 프레젠테이션 층 및 
응용 프로그램 층 두 개가 더 있습니다.
이들은 웹 브라우저, Skype, HTML 디코딩,
스트리밍 영화 등을 포함합니다.
이것들에 대해서는 다음 주에 대해 이야기 할 것입니다.
그때 만나요~
