[컴퓨터 네트워크] Application Layer

학교에서 들은 컴퓨터 네트워크 강의 내용을 복습하면서 작성한 글입니다.
March 24, 2024 10:57 PM

 

Creating a network app

• 전송장치를 위한 소프트웨어 작성 필요 X
• end system 사이에서 작동할 business logic 만 고려하면 됨 (부담⬇️)
  • 계층구조로 이루어져있기 때문?

Client-sever Paradigm

• server
  • 항상 돌아감 (always-on host)
  • permanent IP address → 안그러면 접근마다 새로운 주소 찾아가야함
  • 데이터 센터
• client
  • 서버와 연결, 커뮤니케이션
  • 받고자하는 시점에만 연결되어있으면 되므로 → 간헐적 연결
  • dyanmic IP address(사용하는 동안)
  • client 끼리 직접 연결 X , 서버를 통해서 연결

Peer-peer(P2P) architecture

• 역할 구분이 명확하지 않음, 양쪽 포지션 모두 될 수 있음
• 항상 on 되어있는 것이 없음
• 동등한 peer(end system)끼리 직접적으로 커뮤니케이션
  • self scalability: 새로운 peers 가 나타나면 스스로 규모를 획장
• peers 들은 간헐적으로 접속했다, 안했다 식으로 연결되어 있고 IP 주소가 동적으로 바뀜 (이전 사용 주소와 달라도 OK)

Process Communicating

• process: 호스트 내에서 돌아가는 프로그램
  • 호스트 내에서, 두 process는 IPC(Inter-process communication)을 이용해서 통신
  • 다른 호스트들에 있는 process는 message를 교환함으로써 통신
• Client-Server 구조에서는 server는 데이터를 제공하기 위해, client는 받기위해 다른 process를 가지고 있지만
• P2P 구조에서는 client process(요청으로 시작) 와 server process(요청시까지 대기후 응답)가 있음

Socket

• interface의 이름, 인터넷 어플리케이션 짤 때 쓰는 API
• Process가 message를 주고 받는 경로
  • sending process는 socket 바깥 쪽의 transport 구조에 의지 → 받는 쪽의 socket에 전달되도록
  • socket interface에서 요구하는 것 전달만 하면 → socket이 알아서 전달해주기 때문에 어떻게 목적지까지 도달할지는 고민할 필요 없음

Addressing Process

• addressing: process 지침- 어디로 보냈으면 좋겠다는 정보
• identifier (id) 가 있어야 메세지 받을 수 있음
• id = IP 주소 + port number(16 bit, transport 계층에서 쓰임)
• host device는 고유의 32bit IP 주소를 가짐 (IP: id의 일종)
  • unique하단 말은 사실 틀림: 하나의 host 컴퓨터에도 여러개의 IP 주소 있을 수 있음

Application Layer Protocol

어플리케이션 계층 프로토콜이 정하는 것

• message의 타입: request, response
• message syntax: 어떤 field, 어떤 size 등 정해놓음
• message semantics: 의미
• rules: 언제, 어떻게 process가 message 보내고 응답

프로토콜의 종류

• open protocols : IETF(인터넷의 표준 프로토콜 결정 단체)에서 RFC(문서이름) 결정
  • 어떤 제조사든 protocol 따르면 다른 제조사와 호환 가능
  • interoperability(상호운영성)
  • HTTP, SMTP 등
• proprietary protocols
  • 공개되지 않은 회사 고유의 자산
  • Skype, Zoom 등

Transport service requirements

• data integrity: 주고 받는 data의 무결성 보장(훼손, 조작 시 수신자 측에서 발각)
  • 100% 보장하는 것도
  • 일부 loss를 tolerate 하는 것도 있음 (예: 오디오 데이터)
• throughput: bandwidth
  • 항상 minimum 보장되어야 하는 것
  • 들쭉날쭉(elastic)해도 ok 인 것도 있음
• timing
  • delay가 적어야 effective 한 것들이 있음 (예: Internet telephony - loss는 괜찮지만 delay는 용납 x)
• security
  • 정도의 차이가 있을 뿐 요구하지 않는 것 X
  • encryption

Internet transport protocols services

application layer는 transport layer의 서비스를 이용한다!!!

1. TCP service
   • reliable transport: sender process가 보낸 그대로 오류 없이 수신자에게 도착하는 것을 보장
   • flow control(흐름 제어): receiver의 빈 공간 만큼만 새로운 데이터 보내서, 넘치지 않도록
   • congestion control(혼잡 제어): 네트워크 내에서 일어나는 혼잡 탐지, 조금씩 천천히 보내는 등의 작업(throttle sender)
     • sender-reciever은 많은 쌍이 가능하나 사용하는 network core는 공통이기 때문에 발생가능
   • connection-oriented: 예약 제공(자기들끼리만 알고있는)
   • 보장 X: timing, minimum throughput guarantee, security(-별도의 layer에서 보장)
2. UDP service
   • unreliable data transfer: 의도적으로 신뢰성을 훼손하는 것은 아님, 단지 보장하지 않는 것일 뿐
   • reliability, flow control, congestion control, timing, throughput guarantee, security, or connection setup 등 보장 X
   • 그렇다면 왜 UDP 사용?
     • 매우 간단!!! 3계층과 비교해서 추가적으로 해줄 것이 별로 없음(port number 말고는)
     • TCP는 규약에 따라 제약이 있지만, UDP는 congestion control에 따를 필요가 없으므로 이기적으로 행동이 가능
   • 응답이 굳이 필요 X → 이기적 행동 가능, 오버헤드 부담 ⬇️, 신속 

Securing TCP

• 인터넷의 상업적 사용이 증가하면서 → security의 필요성이 ⬆️ transport layer위에 하나 더해서 보안 ⬆️
• Vanilla TCP&UDP sockets
  • enctyption 없어서 전송중인 packet을 sniffing 이 가능했음
• SSL 등장
• but 보안상 문제 → 해결
• TLS (Transport Layer Security)
  • encrypted(패스워드 암호화)
  • data integrity: 훼손 시 수신자가 발각 가능
  • authentication: 보낸 사람의 인증 정보 포함(예: 서명-private key, 위조불가)
  • application layer과 transport layer 사이에 implemented

•