인강) 컴퓨터 네트워크 기본 2

강의링크 www.kocw.or.kr/home/cview.do?mty=p&kemId=1169634

전주 내용 요약 해주심

TCP/ UDP
패킷 기반 전송 - 라우트를 통해 이동함(series of routes)

패킷 기반 전송에서 4가지의 delay
nodal processing - 비트에 에러가 있는지 없는지 검사 및 목적지로 도달하기 위해 어떤 link를 통해 가야할지 결정함.
queueng - 다수의 사용자가 이용하게 되면 패킷 처리를 할 수 있는 라우트의 capa 보다 넘치게되 된다. 그러면 out going 으로 가기 전 queue 라는 공간에 대기하게 되고, queue도 넘치게 되면 패킷 유실이 발생한다. 패킷 유실의 대부분은 라우터에서 발생하며, 링크에선 거의 발생하지 않음. 
transimission - 라우트 내부에 비트 단위의 정보들이 모여 하나의 패킷으로 모여 out going link로 나감.
propagation -링크를 통해 다음 라우트까지 이동함.

금주 내용

Caravan Analogy - 10비트 짜리 패킷이 두번째 라우트까지 도달하는 시간을 구할 수 있는가? 문제 해설
문제의 핵심은 패킷의 앞부분들은 이미 링크를 통해 빛의 속도로(광섬유) 다음 라우트로 이동해있고 이전 비트들은 transmission 중임. 그래서 앞 비트들은 다음 라우트에서 기다림.

라우트 내용 끝

네트워크 계층

Layer : App (2주) - Transport (3주) 중간고사 - Network - Link - Physical ...

각 계층(Layer)마다 프로토콜이 많이 있으나, 본 강의에서는 굵직한 것 들만 볼것임. App - HTTP, Transport - TCP/UDP, Network - IP, Link - Wifi, LTE, Ethernet... 

금 주 내용은 HTTP 내용을 포함 할 것임. 

Application은 e-mail, web, text messaging, P2P file sharing, voice over IP. 프로세스에서 어떻게 네트워크를 쓰는가에 대해서 알게 될 것이지만, 여러분은 컴퓨터 공학을 전공자 이므로 직접 이 프로세스가 통신하는 것을 만들어 보는 과정을 거치게 될 것이다. 실질적으로 앱 단에서 네트워크 관련 서비스를 구현할 때, 그 내부에서 Router가 어떻게 동작하는지는 신경쓸 필요는 없을 것이다. 단지 상대 Applicatioon이 어떤 방식으로 네트워크를 쓰는가에 대해서 주로 신경쓰면 될 것이다. 그리고 편의를 위해 여러분들이 익숙한 Application부터 강의를 진행하게 되지만, App 밑의 Layer인 Transport, Network 계층은 다룰 것이다. TCP/UDP 그리고 IP를 반드시 다뤄야 하므로 이야기가 안 나올수가없을 것이다. 

Application에서의 네트워크는 Client-Server Architecture로 구성되어있는데, 서버와 클라이언트의 특징은 다음과 같다.

Server:
- 항상 동작하고 있어야한다.
- 영구 IP 주소를 가지고 있다.
Client:
- 서버와 통신한다.
- 동적 IP 주소를 가질 수 있다.
- 다른 client 들과 직접 통신하지 않는다.

클라와 서버가 네트워크 통신을 할 때 IPC(Inter process communication)을 위해 OS가 인터페이스를 제공하는데 그것은 socket이다. 같은 PC 내부에서 동작하는 IPC를 이용할 땐, OS가 프로세스를 위해 system call이라는 인터페이스를 추가적으로 제공하는데, 그와 같은 맥락이다. 다만 네트워크 통신 IPC는 다른 PC 상의 프로세스간 일어나는 것이 다른 특징이다. P1과 P2의 소켓이 연결되면, P1이 write, P2가 read 하는 것이 socket의 역할이고, 네트워크의 동작 원리이다.

P1과 P2가 연결되기 위해서는, 프로세스가 서로의 소켓 주소를 알고 있어야하는데 소켓의 주소를 indexing하는 것이 필요한데, 그것이 바로 IP 주소와 Port 번호의 조합이다. 데스크탑 내부에 여러 프로세스가 돌아가고 있는데, 그 프로세스의 소켓을 지칭하기 위해선 Port가 필요한 것이다. IP는 컴퓨터이다. 

왜 웹 서비스들의 포트는 모두 80(http) 또는 443(https) 일까? 네이버, 아마존, 등등. 그 것은 하나의 약속으로서 자리매김한것이다. (자체 추가 검색 자료 : 네트워크 통신에서 포트를 왜 사용 하는가? Well-known port란. jwprogramming.tistory.com/26 Keyword : IANA, 0~0123 well known port. ) .

계층의 역할은, 하위 계층이 상위계층에게 서비스를 제공해준다. 예로, Application의 하위계층은 Transport 계층이므로, Transport 계층의 서비스를 받는다. Application이 Transport 계층으로부터 받아야 하는 서비스는 다음과 같다.

data integrity 
- App이 보낸/받는 데이터가 유실되지 않고 100% 신뢰성있게 제공되면 좋겠음.
- App이 보낸/받는 데이터가 일정 수준의 유실을 허용했으면 좋겠음.
timing
- App이 보낸/받는 데이터가 특정 딜레이 내에 도달했으면 좋겠음. (latency : elapsed time from source to destination.)
throughput
- App이 보낸/받는 데이터의 용량이 최소화 되었으면 좋겠음.
- App이 보낸/받는 데이터의 용량은 상관이 없고, 사용만되면 됨.
security
- 데이터가 안전했음 좋겠음.

Transport 계층은 data integerity만 제공을 해준다. 그 외의 기능이 필요하다면, Application 계층에서 구현이 되어야한다. 예로, Security를 충족하기 위해 보안 프로그램을 얼마나 설치해야하는지 상상해볼 수 있다.

timing(latency) vs troughput (www.dnsstuff.com/latency-throughput-bandwidth, www.youtube.com/watch?v=4V1ynaj6dq8&ab_channel=Udacity) latency와 throughput의 공통점은 시간이나, latency에서는 각각의 데이터 패킷에 대해 중점을 두나 (예로 롤 이나 음성 딜레이, 1ms delay. lower latency is good. ), throughput은 특정 시간동안 총량의 패킷 크기만 채우면 된다. (예로 다운로드시 1mb per seconds). (나의 생각 : 둘은 상관관계가 있으나 인과관계는 아니다. latency가 좋아도 throughput이 좋지 않을 수 있지 않을까?)

application | application layer protocol | underlying transport protocol

e-mail        |  SMTP                                | TCP
remote terminal access | telnet             | TCP
Web           | HTTP                                 | TCP
file transfer | FTP                                  | TCP
streaming multimedia | HTTTP             | TCP or UDP
Internet telephony | SIP, RTP, Proprietary | TCP or UDP

우리가 처음 배울 Protocol - HTTP

Hypertext Transfer  Protocol
- Hypertext란 텍스트긴 한데 중간 중간에 다른 텍스트 문서로 Linking하는 링크가 있는 텍스트.
- 서버에게 HTTP reqeust <-> 클라이언트에게 HTTP response
- HTTP가 사용하는 transport layer의 TCP 서비스를 씀. 그래서 HTTP를 사용하기전 TCP connection을 시도가 선행되어야함.
- HTTP는 stateless 이다. 서버는 HTTP request 들어오면 HTTP response를 보내주는 작업에만 집중한다. 그 외의, 클라이언트 식별등의 작업은 하지 않는다.(존나 base 내용임 중요하다. victorydntmd.tistory.com/286, stackoverflow.com/questions/13200152/why-is-it-said-that-http-is-a-stateless-protocol)
- None Persistent HTTP 와 Persistent HTTP가 존재하는데, HTTP response후 TCP 연결을 끊어버리는 것이 None Persistent HTTP이다. 
절차 is following : 
1 client TCP request
2 server TCP resopnse
3 client HTTP request
4 server HTTP response and TCP Close
5 client data parsing. 

만약 클라이언트가 데이터를 재 요청하려면 TCP request를 수행해야한다. 즉 1~5의 프로세스를 반복해야함. Persistent HTTP인 경우 TCP가 연결되어 있으므로 3번부터 수행하면 된다.

인강 학생의 질문 47:30~ . 4번 절차에서 서버에서 왜 TCP 끊어버리나? 
- 교수님 답변 : 4번 그림에서 간소하게 표현되었지만, 실질적으로 TCP를 끊어버리기 전에 client와 server에서 상호 협의 후에 끊어버리게 된다. 예로 들면 server에서 끊을 준비를 하는 것이고, client에서 판단하여 close 요청을 하는 등의 방식. 이라고 설명하심.

None Persistent HTTP 는 pipe line 형식으로 요청. 

추후에 위의 내용은 한번 더 반복하여 다룰 예정입니다. 강의는 여기까지.