|
| 1 | +# 7. 응용계층(4) & 8. 전송계층(1) |
| 2 | +## Internet 에서의 ID(기계) |
| 3 | +----- |
| 4 | +### IP |
| 5 | +- IPv4 : 32Bit = 8Bit * 4 (xxx.xxx.xxx.xxx) |
| 6 | +- IPv6 : 128Bit = 16Bit * 8 (xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx) |
| 7 | +### Domain Name |
| 8 | +- 순수하게 인간을 위한 시스템 |
| 9 | +- 응용계층(인터넷 5계층)에서만 관여 |
| 10 | + |
| 11 | +## DNS(Domain Name System) |
| 12 | +----- |
| 13 | +- Domain Name을 IP 주소로 바꿔주는 서비스 |
| 14 | +- Aliasing 관리 |
| 15 | +- 전 우주적으로 중앙관리 |
| 16 | +- 분산관리(계층적 분산관리) |
| 17 | +- DNS의 계층 |
| 18 | + - Root Name Server |
| 19 | + - Top-Level Domain Name Server 관리 |
| 20 | + - Top-Level Domain Name Server의 IP를 반환(유효기간과 함께) |
| 21 | + - 유효기간 동안은 동일한 Top-Level Domain Name Server IP 요청 X |
| 22 | + - Top Level Domain Name Server(ex. .kr, .com, .org, .net) |
| 23 | + - Authorized Domain Name Server(ex. kau.ac.kr) |
| 24 | + - Local Domain Name Server |
| 25 | +- DNS의 동작 방식 |
| 26 | + - Recursive Domain Name Resolution |
| 27 | + - Iterative |
| 28 | + |
| 29 | +## P2P(Peer-to-Peer) |
| 30 | +----- |
| 31 | +- 서버 없이 단말(Peer)들끼리 직접 상호간 서비스를 제공하는 시스템(물물교환) |
| 32 | +- 서비스 보장 X |
| 33 | +- Peer들은 IP를 바꾸며 옮겨다닐 수 있음 |
| 34 | +- Hybrid P2P |
| 35 | + - 서비스 메타 정보는 서버가 관리 |
| 36 | + - 실제적 서비스는 Peer 끼리 |
| 37 | + - Skype, Starcraft |
| 38 | +- Pure P2P |
| 39 | + - 문제점 |
| 40 | + - Peer가 없다 |
| 41 | + - 신뢰 X - 해쉬코드 |
| 42 | + - 이기적 |
| 43 | + - 조각들의 쏠림현상 |
| 44 | + - Torrent, Bitcoin |
| 45 | + |
| 46 | +## Reliable Networking(End-to-End) |
| 47 | +----- |
| 48 | +- 현실 네트워크의 문제 |
| 49 | + - 무한한 흐름 X |
| 50 | + - 패킷 유실 |
| 51 | + - 패킷 순서 바뀜 |
| 52 | + - 패킷 변조 |
| 53 | + |
| 54 | +- 통신 오류 케이스 |
| 55 | + - 패킷이 가는 과정에서 유실되는 경우 |
| 56 | + - ACK가 돌아오는과정에서 유실되는 경우 |
| 57 | + - 걸린 총 시간보다 타임아웃이 일찍 걸리는 경우 |
| 58 | + |
| 59 | +## 성능향상(Pipelining) |
| 60 | +----- |
| 61 | +- 연속된 대량의 작업이 순차성을 갖고 있으나 앞의 일이 종료하지 않고도 다음 일을 시작할 수 있는 병렬성을 가진 경우 성능 향상 기법 |
| 62 | + |
| 63 | +### Pipelining의 2가지 기법 |
| 64 | +#### Go-Back-N |
| 65 | +- 최대 N개의 패킷을 병렬적으로 처리 |
| 66 | +- 송신측에서는 N개의 패킷을 Buffering |
| 67 | + - Buffering의 의미 : 수신이 확실하지 않은 패킷에 대하여 재전송을 위하여 보관 |
| 68 | +- 수신측에서는 순차적으로 잘 수신된 패킷에 대히여 ACK를 송신하고 패킷의 Payload를 응용계층으로 올려보냄 |
| 69 | +- 송신측에서는 Buffer에 여유가 생기면(ACK를 받아서) 그만큼 추가로 Pipelining |
| 70 | +- 수신측에서 순서에 맞지 않는(이빨이 빠진) 패킷이 온 경우 반응 2가지 옵션 |
| 71 | + - 조용히 있음 |
| 72 | + - 잘 받은 마지막 패킷에 대한 ACK를 전송 |
| 73 | +- Go-Back-N에서의 재전송 정책 |
| 74 | + - 각 패킷 전송 시에 패킷을 위한 타이머를 설정 |
| 75 | + - ACK를 받으면 ACK 해당 패킷과 앞쪽 패킷에 대한 타이머 소멸 |
| 76 | + - 타이머 이벤트 발생 시 해당 패킷부터 재전송 |
| 77 | + - 추가 전송 정책 : K번째 패킷에 대한 ACK이 반복적으로 올 경우 K+1번째 패킷의 유실을 함축 |
| 78 | +- 장점 |
| 79 | + - 단순함(특히 수신측에서) |
| 80 | + - 간명하게 시스템의 상태가 추상화 |
| 81 | +- 단점 |
| 82 | + - 패킷 유실에 대한 복구비용이 많이듦 |
| 83 | +#### Selective Repeat |
| 84 | +- Go-Back-N의 단점 보완 |
| 85 | +- 수신측에 버퍼를 둠 |
| 86 | +- 빠진 패킷이 있을 경우 그 뒤 쪽의 잘 도착한 패킷들은 버퍼에 보관 |
| 87 | +- 빠진 패킷이 추후 도착하면 버퍼에 저장한 이후 패킷들까지 순차적으로 응용에 전달 |
| 88 | +- 장점 |
| 89 | + - 실패한 패킷만 재전송(성능UP) |
| 90 | +- 단점 |
| 91 | + - 시스템 추상화 복잡 |
| 92 | + - 수신측에도 버퍼가 필요 |
0 commit comments