이석복 네트워크 (2)복습, 유명한 애들, application, process, IP, socket, port, 계층이란, HTTP, persistent
===
http://ocw.hanyang.ac.kr/?course=8479
컴퓨터네트워크_2회차
컴퓨터네트워크 기본2 (Computer Networks and the Internet) 컴퓨터네트워크 및 인터넷 역사 (Internet history)
ocw.hanyang.ac.kr
===
인터넷에서 제공하는 전송 서비스 TCP / UDP : 신뢰성 유무 등
===
패킷기반
데이터가 패킷이라는 한 묶음 단위로 이동
패킷은 결국 비트들의 집합.
출발지 - 라우터 - 목적지
===
라우터에서 패킷을 받아서 알맞은 방향으로 보내준다
몰리면 문제가 된다
라우터가 아웃고잉엣지로 뿜어내는 양보다 많은 패킷이 들어오면 큐에 패킷이 쌓임 = 딜레이
쌓이다가 큐라는 버퍼공간보다 들어오는 패킷수가 많으면 유실이 일어남
===
딜레이 4
검사, 큐, 트랜스미션, 프로파게이션
===
Caravan analogy, 라우터에 생기는 딜레이를 고속도로 상황에 비유한 것
차량 10대가 항상 한꺼번에 다녀야 하는 상황, 수행원 같은 것
차량 1대는 비트, 차량 10대는 패킷
톨게이트가 라우터
100km가 프로파게이션딜레이
12sec : 트랜스미션 딜레이
딜레이는 이거 두개만 있다
답: 맨 마지막 차를 생각해야하니까 2분 더하기 60분
프로파게이션딜레이는 빛의속도라서 링크로 뿜어져 나온순간 도착한다
패킷의 앞부분은 다음 라우터에 도달해있고, 이전 패킷은 이전 라우터에 있는 상황
다음 라우터에서는 모든 패킷이 다 올때까지 기다린 다음에 진행한다 이게 패킷 스위칭
앞의 패킷이 다음 라우터에 도달했다고 해서 걔가 진행되면 안됨
===
한학기동안 네트워크 계층을 위에서부터 얘기할 것
오늘부터 애플리케이션 레이어, 친숙하고 어려운게 없어
탑다운으로 얘기하면 친숙한것부터 하니까 부담이 없는데 얘 얘기를 할 때 아래 계층 얘기(TCP, IP..)가 안 나올 수가 없다 일단 그냥 그런게 있구나 해야해
===
레이어는 개념적으로 나눠놓은 것
실제로 계층안엔 다양한 프로토콜이 존재한다
제일 유명한 애들
어플리케이션 레이어 : HTTP..
트랜스포트 : TCP
네트워크 : IP
링크 : Wifi, LTE, 유선Ethernet
각 계층에서 굵직굵직한 프로토콜을 볼 것
▽수업에서 4개의 계층을 다루네!
===
애플리케이션 = 프로그램
코드짜고 컴파일하면 실행파일 나오고 실행하면 프로세스로 되고 프로세스가 일을하고 그거
애플리케이션 레이어 : 네트워크 기능이 있는 프로세스다 = 가장 흔한 네트웍 기능이 있는 프로세스가 웹브라우저
반대편에 있는 프로세스와 프로세스간의 통신을 신경쓰면 된다, 하나는 웹브라우저 하나는 웹서버
가운데 라우터는 신경 안써도 된다. 계층이라는게 네트워크 엣지에만 존재하는거고, 라우터는 네트워크 레이어까지만 존재해
===
네트워크 애플리케이션은 네트워크엣지에 있는 서버와 클라이언트에 동작하는건데
그래서 서버/클라를 좀 자세히 알아보면
클라 = 웹브라우저
서버 = 웹서버
인터넷 상에 존재하는 모든 컴퓨터들은 각자의 주소를 갖고 있어야 하고 그게 IP주소,
서버는 24시간 동작해야하고, permanent IP address가 있어야한다. 고정된 IP주소. 그래야 사람들이 찾아가
클라이언트는 고정 안돼도 돼
OS나 시스템프로그래밍에서도 인터프로세스커뮤니케이션, 프로세스 사이의 통신할 때 OS가 인터페이스를 만들어놓음
이것도 결국은 클라이언트 프로세스와 서버 프로세스 사이의 통신이다.
이건 다른 컴퓨터에 위치한 프로세스간의 통신. 별 차이 없다. 다른 컴퓨터 상에 위치한다는 것 뿐. => OS내부에서 다 만들어놨다 = 소켓
한 프로세스에서 소켓에 write하면 다른쪽에서 read가 되는. 이렇게 데이터 전달이 된다
이렇게 연결을 시켜놓으려면 소켓끼리 주소를 알아야 한다
소켓의 주소 역할을 하는 인덱싱이 필요해 = IP adress + port
IP : 인터넷 안의 컴퓨터구분
포트 : 그 컴퓨터 안에 여러 프로세스들 구분(포트에 물린 소켓이 누구냐)
===
다른 컴퓨터에 위치한 프로세스를 지칭하는 인덱스가 IP+port
웹브라우저가 다른 컴퓨터의 프로세스랑 연결이 되는 것
예를 들면 네이버 프로세스에 해당하는 소켓의 주소(▽컴퓨터가 아니고 소켓!)를 입력해야 www.어쩌구.. .com 으로 이게 원래는 IP주소+포트넘버로 입력해야됐던 것. 숫자 외우기 싫어서 DNS 시스템으로
DNS까지 써도 www..어쩌구:80 이 80을 써줘야 하는데 80번은 입력 안해도 된다
웹서버를 운영하는 거의 모든 서버들이 포트를 80번을 쓰고 있다. 아마존 네이버 구글... 거의 모든 웹 서비스
왜? DNS는 단순히 IP주소만 번역해줘. 그럼 포트넘버가 필요한데 서버마다 포트가 다 틀리면?
이렇게 안하면 DNS에서 포트까지 다 해줘야 한다
그래서 포트넘버를 통일해서 쓰자가 됨
네트워크를 가르치는 교수는 어느 대학이든 401호에서 강의하자 찾아가기 쉽게
랑 같다
===
계층이란 개념은, 하위계층에서(n이 작은값), 상위계층(n이 큰값)한테 기능을 서비스를 제공하는 것
애플리케이션레이어 프로토콜들은 바로 하위 계층인 트랜스포트레이어에서 제공하는 기능을 사용한다. 서비스를 받는다
애플리케이션 개발자가 트랜스포트 계층에서 이런 서비스를 제공해줬으면 좋겠다 하는 희망사항이 있을거고 나열해보자
1.내가 보내는 데이터가 유실되지 않고 온전하게 목적지까지 도착했으면 좋겠어요
2.개별적인 시간에 대한 얘기. 적어도 얼마의 시간내에 도착했으면 좋겠어요, 음성 같은것. 음성 패킷이 도달하는 타이밍이 중요한 것
3.양에 대한 얘기. 1초에 어느정도 양이 도달해야한다(2.랑 다르게 모든 패킷이 어떤 타이밍을 맞출 필요가 없다)
*1메가 바이트에 해당하는 모든 데이터가 timing을 맞출 필요가 없다 하나도 안가고 있다가 마지막에 확 가버려도 된다
영화 다운로드 받는 것. 이건 timing이 중요한 게 아니다
4.보안
*integrity : 진실성
transport layer가 실제로 이 중에서 제공해주는건 data integrity뿐. TCP라는 프로토콜이 제공해준다. UDP는 그것도 제공안해줘
2.3.4.가 필요하다? 현재는 트랜스포트레이어에서 안해주니까 애플리케이션 레이어에서 지지고볶고 해야한다
보안같은것도 아래서 안해주니까 애플리케이션 레이어에서 하고 있다. 난리치면서 뭐깔아라뭐깔아라 하면서
===
유명한 어플리케이션들이 어떤 프로토콜 쓰는지
▽이걸 애플리케이션이 뭐쓸지 정하는거구나 Web은 앱이구나
가장 유명한게 Web을 동작시키고 있는 HTTP. 이걸 설명할 것
===
HTTP란
프로토콜인데 뭔갈 트랜스퍼해 뭐를? 하이퍼텍스트를
하이퍼텍스트는 뭔데? 그냥 텍스트인데 중간중간에 링크(다른 텍스트를 지칭하는)가 있는 것
이걸 전송한다고 ▽링크가 있는 텍스트를 전송하는 프로토콜!
request 내가 원하는 하이퍼텍스트 파일 이름을 대고, 주세요
response 응
끝
메시지 종류가 2개밖에 없다
단순해서 얘기할 게 없다
===
HTTP는 애플리케이션 레이어 프로토콜이기 때문에 당연히 트랜스포트레이어서비스를 사용한다. 그중에서도 TCP
TCP를 사용하기 때문에!! request, response HTTP 메시지가 교환되기 전에 TCP 커넥션을 해줘야한다
stateless
HTTP가 단순해서 request가 들어오면 해당하는 파일디스크를 읽어서 response에 담아 보내주고 끝
더 이상 기억 안해 전혀 상대방에 대한 상태를 기억하지 않아
===
HTTP는 TCP커넥션을 사용해서 기반으로 그 위에서 메시지를 주고 받는다고 했는데
(▽HTTP가) TCP커넥션을 사용하는 방식에 따라 2가지로 나눠진다
TCP커넥션을 persistent하게 사용할거냐
말거냐
- TCP커넥션 만들고 HTTP메시지를 주고받고 끊으면 non-persistent
- 끊지않고 유지하면서 재사용 하는게 persistent
===
네이버 기사를 불러올거야, 그림 있는
메인페이지를 요청하기 위해 TCP커넥션 생성
메인페이지에 대한 request
메인페이지에 대한 response
TCP끊고
다시 TCP커넥션 만들어서 각각 그림을 가져오게 되면 non-persistent
안끊고 그림가져오면 persistent
===
non-persistent는
10개의 이미지가 레퍼런스 돼 있다
TCP커넥션을 만드는 메시지가 왔다갔다한다, 연결하고 싶어. 알았어 연결하자.
TCP커넥션을 바탕으로 해서 이 위에서 하이퍼텍스트파일에 대한 request response
4.그리고 끊어
그리고 웹브라우저가 home.index파일을 파싱해. 그 중에 ref하고 URL있어(10개 그림 파일). 파일 몇개 더 가져와야되네?
TCP끊겼으니 다시 똑같은 과정 반복
▽그 이미지가 다른 서버에 있을 수도 있지 않나 여기선 같은 서버?
연결 첫번째 그림 끊고
연결 두번째 그림 끊고
...
===
persistent는 좀 수월.
현재 웹브라우저에서는 default로 persistent를 사용한다
===
TCP커넥션 끊는건
서버가 난 보낼건 다 보냈다 하고 끊을 준비를 해
그 다음 클라이언트가 판단한다. 정말 다 받았으면 끊어. 양쪽에서 다 끊어줘야 끊김
===
persistent에서 TCP연결 유지하면서
하나 요청하고 받고
하나 요청하고 받고 하는게 기본인데
실제 쓰는 좀 더 나은 방식이 그림 4개면 요청을 4개 연달아서 보내고 4개를 연달아서 받아
파이프라인과 persistent HTTP가 결합된 방식