모범생님의 이글루

단어
1,2장단어 41-82번
3장단어 15-28번
4장단어 5-8번
5장단어  8-17번
6장단어 10-18번
7장단어  8-14번
9장단어 전부

발표
4장 - 발표
6장 -
9장 9.4.3 ~ 9.4.4
11장 11.3.4 ~ 11.3.5

퀴즈
3장 3문제
7장 3문제
10장 -

정확히 어느부분을 내가 맡아서 하였는지 조금 기억이 나지 않는 부분도 있어
그 부분은 공백으로 두었습니다..

이번 시간에는 예습한 대로 라우팅에 대하여 수업을 하였다.
항상 복습 블로그를 써온 방법대로 이번에도 역시 수업을 통해 새롭게 알게 된 점들에 대해 복습을 하였다.

간접 라우팅의 경우 라우터에 어느 경로를 통하여 다음 라우터로 갈지를 각 라우터에 있는 라우팅 테이블에서 길을 찾아 간다고 배웠다. 먼저 라우팅 테이블을 목적지 네트워크와 인터페이스만을 표시하여서 라우팅 하여 길을 찾아 가는것에 대해서 설명을 들었는데 이경우 어떤 방식으로 라우팅 테이블을 통해 길을 찾아 가는지 이해하기는 쉬웠지만 교수님이 말씀 하신대로 인터페이스를 통하여 나간 길 다음에 나오는게 다음 라우터가 아니라 네트워크등을 통하여 다음 라우터로 가야 하는 경우에는 이런 방법으로 설명이 되지 않았다. 실제 라우터에는 인터페이스만이 적혀있는 라우팅 테이블이 있는 것이 아니라 서브넷마스크와 목적지 네트워크, 그리고 넥스트 홉의 주소와 함께 인터페이스 정보가 적혀 있기 때문에 다음 라우터를 찾아 갈 수 있는 것이라고 하였다.

직접 라우팅 테이블을 작성하는 연습을 해 보았다, 라우팅 테이블을 작성할 시 먼저 기준 라우터를 보고 목적지를 가기위해서 기준 라우터에서 처음 거치는 라우터의 주소가 넥스트 홉의 정보가 되었고, 목적지의 주소를 보고 마스크를 결정해야 했다. 그리고 목적지로 가기위한 나아가야 할 길이 인터페이스 정보가 되었다. 라우팅 테이블의 마지막에는 각각의 테이블 정보에 속하지 않은 주소에 대한 처리를 위하여 마스크 주소와 목적지 주소모두 0.0.0.0 인 정보를 입력시켜 주어 나머지 주소들을 처리하였다.
만약 목적지 주소까지 가는 길이 한가지 경우가 아니라면 여러 경로중의 한가지경우를 선택하여 테이블 정보를 입력시켜 주면 되었다. 직접 라우팅 테이블을 작성해 보니 좀더 확실히 라우팅 테이블에 대해서 이해할 수 있었다.

CIDR은 기존의 클레스의 개념이 없는 IP주소라고 하였다. CIDR의 서브넷 주소는 IP주소 뒤에 /숫자(CCNA에서 배운 바로는 prefix)를 넣어 구별한다. 뒤에 붙는 숫자는 마스크 주소의 1의 갯수로 앞에서부터 숫자만큼의 비트수가 마스크 주소가 되는 것이다.

라우트 결합이란것은 수퍼네팅과 함께 생각해 볼 수 있었다. IP주소를 광과할때 각각의 네트워크 주소에 대해서 다 광고를 하여야 하는데 수퍼네팅을 통하여 네트워크 주소를 더 큰 네트워크 주소 안에 포함시켜 한개의 네트워크 주소를 광고하는 것이다.

외부 내부 프로토콜에 대해서 예습을 할 때 잘 이해하지 못하였다고 하였는데 수업시간에 교수님도 별로 중요하게 설명하지 않으신 걸로 보아 중요한 내용이 아닌듯 하다. 내부 게이트 웨이 프로토콜은 AS내에서, 외부 게이트 웨이 프로토콜은 AS들 사이에서 사용하는 것이라는 건 알았지만 AS가 무엇을 뜻하는지 잘 모르겠다.

RIP에 대해서 배우면서 이해가 되지 않는 부분이 있었다.
RIP 라우팅 테이블 갱신 부분(PDF자료 26페이지)에서 Net2 에 대한 정보는 2 → 5로 갱신되었고, Net8에 대한 정보는 8 → 5로 갱신되었다. 그리고 Net9 에 대한 정보는 갱신 메시지에서 6을 보내줬지만 원래 값인 4보다 크기때문에 갱신되지 않는다고 하였다. 하지만 그렇게 본다면 Net2 에 대한 정보도 원래 값인 2보다 새 값이 5가 더 크기때문에 갱신되지 않아야 하는게 아닐까??하는 의문이 생겼다.

OSPF라는 것이 있었는데 이것은 소문에의한 라우팅과는 다르게 처음 라우터 부터 모든 라우팅 테이블 정보를 가지고 있기 때문에 결국 총 지도를 가지고 있는 겪이다. 그래서 가장 호스트가 적은 길을 찾아 갈 수 있지만 소문에 의한 라우팅은 바로 다음 갈 길만을 알 수 있다.

지금까지는 서브넷 마스크 정보를 보낼 수 없었기 때문에 동일한 크기로 서브넷을 할 수 밖에 없었지만 CIDR로 인해 마스크 정보를 보낼 수 있게 되어 서로 다른 크기로 가변 서브넷을 할 수 있는 것이다. 가변 서브넷 마스킹을 연습을 하면서 CCNA시간에 배웠던 것들에 대해 다시 떠올릴 수 있었다.

라우팅에 대해서는 얼마전 CCNA시간에 배운적이 있어서 어느정도 내용을 알고있기 때문에 이번 예습은 쉽게 할 수 있을것이라고 생각하였다.
하지만 내가 CCNA시간에 배운게 라우팅의 전부가 아니라는 것을 이번 예습을 하면서 알게 되었다.
쉬울거라고만 생각했었지만 이해하지 못하는 부분도 상당히 있었다.

라우팅 기능이랑 한 장비에서 다른 장비로 논리적 주소(IP주소)를 이용하여 데이터그램을 전달하는 기능이다.
브릿지는 두 지점간의 데이터를 필요에 따라 통과시키거나 필터링 한다.
스위치 : 브릿지와 유사하나 브릿지나 라우터에 비해 높은 성능을 자랑한다.
    공유세그먼트란 복수의 호스트가 연결된 세그먼트 이고, 전용 세그먼트는 하나의 호스트만 연결되어 있는 세그먼트이다.
라우터 : 다른 형태의 데이터 링크 계층 프로토콜을 사용하는 새로운 서브넷이 기존의 네트워크에 추가되다면 인근 세그먼트로 트래픽을 보낼 때는 라우터를 이용하여야 하고, 서브넷들이 WAN 프로토콜에 의해 연결될 때도 라우터가 필요하다.
직접 라우팅 : IP주소가 부여된 2개의 인터페이스가 동일 서브넷에 있는 경우. ARP 프로토콜이 제공해주는 물리 주소로 전달.
간접 라우팅 : 송신지로부터 그와 다른 서브넷이나 다른 네트워크에 있는 목적지까지 데이터그램을 저달하기 위해 제 3자인 IP 라우터를 이용.
IP 라우터가 경로를 찾는 방법
1. 동일 네트워크에서는 지역적으로 직접 연결
2. 이웃한 네트워크에 연결
3. 여러 네트워크들을 가로질러 도달.
어떤 인터페이스가 IP 데이터그램을 목적지로 전달하기 위한 경로에 있는지를 라우터가 결정하기 위해 참조할 라우팅 테이블을 요구
동일 네트워크-동일 서브넷간 : 직접 라우팅으로 데이터그램 전송
동일 네트워크-다른 서브넷간 : 간접 라우팅( 송시지의 서브넷이속한 로컬 라우터가 데이터그램을 일단 수신하여 라우팅 테이블을 참조하여 데이터그램을 목적지 인터페이스로 전달할 수 있는 적절한 경로를 결정.)
라우팅 테이블을 참조할 때 일반적으로 fall-through방식을 사용
fall-through방식 : 제일 위에 위치하는 엔트리부터 참조하여 적합 하다면 그 정보 이용, 적합하지 않다면 아래 엔트리로 내려가는 방법
라우팅 테이블의 내용:
-목적지 네트워크 주소
-서브넷 마스크
-비용/메트릭
-다음 홉 주소/게이트웨이 주소
-출구 인터페이스
(기타)
-프로토콜
-연령
-인터페이스

CIDR
인터넷 주소의 개수를 늘리면 백본 라우터가 유지해야 하는 라우팅 테이블의 크기가 증가된다는 문제가 있음.
CIDR은 기관에 주소를 부여할 때 연속된 주소들을 블록 단위로 할당하여 상황을 완화시키는 방법 제시.
라우팅 테이블 엔트리 결합으로 인해 라우팅 테이블 검색 시간이 줄어들게 되고 전달 지연도 줄어듬.

라우트 결합 : 여러개의 네트워크들이 하나의 주소로 광고될 수 있다면 여러개의 네트워크들이 모여 하나의 네트워크처럼 보이게 됨. 수퍼네팅.

RIP : 가장 간당하고 많이 사용되는 내부 게이트웨이 프로토콜
수동모드에서는 RIP 업데이트를 수신하기만 하고, 능동모드에서는 라우팅 정보의 수신 뿐 아니라 네트워크나 자신에게 연결된 서브넷으로 라우팅 정보를 전송
라우팅 업데이트 : 각 네트워크/서브넷과 그 홉 수의 목록을 전송
홉 수 : 경로상의 라우터 수를 의미. 최대값 16. 회선의 속도나 품질을 나타내지는 않기 때문에 홉수가 적다고 시간적으로 전송이 더 빠름을 의미하지는 않음.
RIP는  홉의 수만 중요하게 생각하고 회선의 품질, 속도나 신뢰성 드은 신경 쓰지 않음.
RIP패킷은 한 라우터가 다른 라우터에게 네트워크에 대해 자신이 알고 있는 것을 알려주기 위한 정보를 포함.

RIP1의 단점
1. 서브넷 마스크를 전달 하지 않음 - RIP로 구성된 네트워크의 각 장비들은 동일한 서브넷 마스크를 가져야 함. IP주소의 낭비
2. 인증기능 없음 -  송신자가 합법적인 RIP장비인지 구별할 수 없음을 의미. 옳지않은 RIP 업데이트 패킷을 만들어 케이트웨이 또는 라우터로 전송 함으로 그 네트워크의 라우팅을 엉망으로 만둘 수도 있음.
3. 업데이트 패킷을 방송함 - 업데이트 받을 필요 없는 일반 호스트들에게도 송신됨으로 트래픽을 발생

RIP2 : RIP1의 단점을 보완하기 위해 등장
인증기능 도입하였고 경로광고에 서브넷 마스크를 포함함. 라우팅 업데이트가 서브넷 마스크를 포함하기 때문에 각 서브넷에 어떤 주소들이 포함되어 있는지 알 수 있게됨,
RIP2 업데이트에 인증 패스워드를 포함.
업데이트 내용을 전송하기 위해 멀티캐스팅을 사용함으로 RIP2를 지원하는 장비에게만 업데이트 패킷이 전송.

OSDF
링크-상태 프로토콜로 홉 수만을 고려하는 것이 아니라 링크와 관련한 모든 요소를 고려, IP의 TOS에서 특별하게 요구하는 요소별로(지연, 처리량, 비용, 신뢰성) 그 요소에 대해 가장 유리한 경로를 찾아줌
라우팅시 동시에 여러 경로들을 이용하여 트래픽을 라우팅하여 트래픽 부하를 분산.
비라우팅 장비가 라우팅 업데이트 정보에 의해서 방해 받는 경우는 없음.
인증기능을 제공함으로 라우팅 업데이트 정보를 생성해서 네트워크 라우팅 능력을 손상시킬 수 없음.

가변 서브넷 마스킹(VLSM) : 기관의 필요에 따라 네트워크에 조정을 가할 수 있는 능력. 각 서브넷들은 서로 다른 서브넷 마스크를 사용할 수 있음.
네트워크 IP주소를 거의 낭비됨이 없이 최대한 활용 할 수 있고, 각 지역들은 서로 다른 서브넷 마스크를 갖고 있음.

3계층 스위치 기술이 관심의 초점으로 부상.
속도가 느린 라우터 대신에 3계층 스위치는 이더넷과 같은 한 가지 물리계층 프로토콜을 지원하고 IP나 IPX와 같은 가장 대중화된 프로토콜만을 라우팅 함.

책에서는 가변 서브넷 마스킹에 대한 내용이 별로 없었지만 교수님의 자료를 보니 가변 서브넷 마스크에 대한 내용이 많았다. 가변 서브넷 마스킹에 대한 내용 역시 CCNA시간에 배운적이 있는 내용인데 만약 A라는 네트워크는 5개의 호스트를 필요로 하고 B라는 네트워크는 40개, C라는 네트워크는 150개의 네트워크를 필요로 한다고 할때 보통의 서브넷 방법 이라면 가장 많은 호스트를 필요로 하는 C라는 네트워크를 기준으로 서브넷팅을 하여 A나 B 네트워크 같은경우는 많은 숫자의 주소를 낭비해야 했지만 가변 서브넷 마스킹은 각각의 네트워크에 필요한 만큼의 서브넷팅을 할 수 있기 때문에 낭비하는 IP주소의 숫자가 줄어들수 있는 것이다.

중간에 수버네팅이나 외부/내부 프로토콜에 대한 내용은 잘 이해가 되지 않았습니다.

이번 수업시간에는 먼저 3-way handshake에 대해서 다시한번 집고 넘어갔다.
먼저 통신을 하는 양측은 송신측과 수신측이라고 나누면 서로 역할이 바뀌기 때문에 설명시 헷갈리게 된다고 하였다.
그래서 송신측과 수신측이 아닌 클리어 언트와 서버측으로 나누는데 서버가 기다리는 입장에서 클라이언트에서 먼저 통신을 하자고 메세지를 보내는 것이다.
의미있는 "데이터"가 들어있는 세그먼트를 보내면 다른쪽에서는 이에대한 수신확인을 보낸다.
세그먼트를 받으면 잘 받았다는 의미로 다음에 오는 SYN값이 xxx가 됐으면 좋겠다고 ACK응답을 보내는 것이다.
먼저 클라이언트측에서 SYN값 (ex 11525)을 보내어 시작 일련번호를 맞춘다.
그리고 그에대해서 서버측에서 잘 받았다는 응답으로 ACK응답 (ex 11526)과 SYN(서버측 시작 번호 ex 256)을 보낸다.
그러면 다시 클라이언트 쪽에서는 ACK응답(ex 257)을 보냄으로써 통신이 시작되고 클라이언트에서 DATA를 전송하는 것이다.
이 경우 SYN값과 ACK값은 서버측에서 응답받은게 없으므로 중복되도 상관없으므로 각각 SYN=11526, ACK=257을 전송한다.

데이터 전송시 클라이언트에서 한번 전송할때마다 서버에서 응답해주는 경우와 여러번의 서버의 데이터 전송에 대해 한번의 몇개에 대해서만 ACK응답을 보내는 경우가 있다.

나머지 HTTP에 대한 내용은 내가 예습한것이 대부분 이었다.
그중 교수님께서 GET와 POST에 대해서 공부해보라고 하셨는데 많은 것을 알아 보지는 못했다.
GET은 일반적인 웹 페이지를 사용하는 것이고 POST는 Form을 채워보낼때 사용하는 것이라는데
GET같은 경우에는 많은 데이터를 보낼때 용량에 한계가 있고, 띄어쓰기나 특수문자를 넘길 경우에는 인코딩을 해줘야 하고, 로그인 부분에서의 보안문제때문에 POST방식을 더 많이 쓴다고 한다.

이번 시간에는 한시간 수업후 나머지 두시간동안에는 HTTP 데이터 전송의 패킷을 분석하는 실험을 하였다.
프로토콜 인스펙터를 사용하여 캡쳐된 패킷을 확인하여 처음 부분에 3way-handshake가 이루어 지는 것에대해 세션비트 플레그를 살펴봄으로써 확인해 볼수 있었다.
그리고 데이터 전송에 대해 서버측에서 ACK응답이 온 내용을 확인해 보았는데 모든 데이터 전송에 대하여 응답을 해온것이 아니라 중간중간의 데이터에 대해서만 임의적으로 ACK응답을 해 옴을 확인해 볼 수 있었다.
전송시간과 ACK응답 도착시간을 확인할 때 조금 헷갈려 어려움을 겪었다.
전송시간을 확인하는데 'arrived at 시간' 이 써있어서 전송시간은 어디있지 라고 고민을 하였는데 캡쳐하는 부분에서 보면 전송을 한 내용이 캡쳐하는 부분으로 도착을 한 것이기 때문에 도착시간이라고 표시되는게 맞다고 한다.
그리고 ACK응답 도착시간을 확인 하면서 ACK응답에 대해서 다시한번 확실히 개념을 잡을수 있었다.
ACK응답이라는게 다음 전송받기를 원하는 값이기 때문에 ACK값과 같은 값이 있다면 그 전에 보낸 데이터에 대해서 ACK응답을 한 것이 되는 것이다.
조금 더 빨리 이해 했었더라면 시간내에 확인을 받고 틀린부분이 있다면 지적받을 수 있었을 텐데 아쉽다.
솔직히 요즘들어서 TCP공부에 대해서 조금 소홀해졌는데 다시 열심히 공부하도록 해야겠다.

HTTP : Hyper Text Transfer Protocol

하이퍼 텍스트 : 다른 데이터로의 연결을 포함하고 있는 텍스트로 앵커와 주소로 이러어진다. 앵커란 텍스트 또는 그레픽으로 이루어진 특별한 위치로 클릭하면 해당 페이지로 이동하게 된다.

URL : 웹서버에 있는 문서들을 간략한 표현으로 구별할 수 있게 해주는 표준 방식으로 6개의 구성요소로 되어있다.(3개의 필수 구성요소와 3개의 선택사항)
3개의 필수 구성요소는 서비스 유형(ex:http, ftp, telnet..등), 시스템 이른, 경로 이름이다.

HTTP의 간단한 모델은 브라우저라 불리는 클라이언트 소프트웨어가 요청을 보내고 서버가 이에대한 응답을 보낸다.
이 사이에 아래와 같이 프록시 서버가 들어가 중개시스탬이 끼어들어 중개한다.
(user      request→    (proxy)     request→      (sever)
agent)   ←response                 ←response
프락시 서버는 클리이언트로서의 역할도 하고 서버로서의 역할도 한다. 클라이언트의 요청을 받아 이 요청을 서버에게 요청하기 전에 해석하거나 다른 서버로 보내기도 한다.
프락시는 접수한 요청 메시지를 다시 기술하고 재가공된 요청을 원래의 서버로 전송한다.
웹 프락시 서버는 최근에 보여 진 페이지를 저장하여 사용함으로써 트래픽을 감소시킨다.

HTTP 연결은 이전에 이루어졌던 요청과 관련없이 독립적으로 이루어진다. 즉, 전에 무슨요청을 어떻게 하였던지 상관없이 요청이 이루어지는 것이다.

HTTP버전 1.0은 비영속적 연결로 열린 상태를 대기하지 않는다.
비 영속성 연결은 아래와 같이 이루어 진다
1. URL의 IP주소와 포트번호에 대하여 TCP 연결을 연다(open)
2. 사용자는 요청해더를 서버에 전송함으로써 서비스 요청을 한다.
3. 서버는 응답해더와 데이터를 포함하는 엔티티헤더를 전송함으로써 작업을 종료한다.
4. TCP연결을 종료하고 작업에 대한 정보는 저장하지 않는다.

HTTP버전 1.1은 영속적 연결을 기본으로 한다.
영속적 연결은 클라이언트가 연결의 종료를 요청하는 경우나 서버의 타이버가 다 할 때까지 추가 요청이 수신되지 않는경우의 두가지 경우에 서버의 연결을 닫는다.

HTTP캐시의 목적은 요청의 발생을 감소시키고, 요청의 전부가 아닌 일부마능ㄹ 보내어 패킷을 주고받는 횟수를 감소시켜 대역폭을 감소시키는 것이다.

내 생각에 HTTP에서 가장 중효한것은 프록시 서버의 중계와 캐시로 인한 트래픽 감소인듯 하다. 물론 영속적 연결과 비영속적 연결의 차이도 알아야 하겠지만 프록시 서버와 캐시로 인하여 트래픽이 감소한다는 내용이 가장 중요한 내용이라고 생각한다.