보다 나은 내일, 다이어리

08-01 상속이란?

B클래스가 A클래스를 상속받으면 B 클래스는 A 클래스의 멤버 변수와 메서드 사용 가능

-> 그 기반이 되는 기술이 '상속'

A 클래스: 부모, 상위 클래스

B클래스 : 자식, 하위 클래스

class B extends A { }

Customer 클래스와 VIPCustomer 클래스를 구현해본다고 하자.

VIPCustomer에게는 일반 고객에게 제공하는 혜택을 기본으로 하고 추가 속성과 메서드를 추가하면 됨.

public class VIPCustomer extends Customer {  }

Customer 클래스에서 사용한 변수인 customerGrade가 private으로 선언되어 있다면 protected로 바꾸자.

상위클래스에서 작성한 변수나 메서드 중 외부 클래스에서 사용할 순 없지만 항위 클래스에선 사용할 수 있도록 지정하는 예약어가 바로 protected ~!

그리고 get(), set() 메서드를 추가하자.

-> private 변수처럼 protected 변수도 외부 클래스에서 값을 가져올 수도, 지정할 수도 있게 된다.

08-02. 상속에서 클래스 생성과 형 변환

하위 클래스가 생성될 땐 상위 클래스의 생성자가 !반드시! 먼저 호출됨.

그리고 상위 클래스 생성자가 호출될 때 상위 클래스의 멤버변수가 힙 메모리에 생성되는 것임.

알고 가자!) 상위 클래스의 private 변수도 생성은 되지만 단지 하위 클래스에서 접근을 못하는 것일 뿐이다!

하위 클래스의 생성자에서 super()를 자동으로 호출하기 때문에 상위 클래스의 디폴트 생성자가 호출되는 것이다.

알고 가자!) super()는 컴파일러가 자동으로 추가하는 코드.

super로 상위클래스의 멤버변수나 메서드를 참조할 수도 있다.

super.showCustomerInfo()

상위클래스로 묵시적 형변환

Customer vc = new VIPCustomer()

VIPCustomer 클래스로 인스턴스를 생성할 때 이 인스턴스의 자료형을 Customer형으로 클래스형 변환하여 선언할 수 있음 = 업캐스팅(upcasting)

하지만, 클래스의 자료형이 Customer로 한정되어졌기 때문에 VIPCusotmer 클래스의 멤버변수와 메서드는 사용 불가능해짐.

만약 다시 사용하고 싶다면 VIPCustomer로 다운캐스팅(downcasting)하면 됨

알고가자!) 모든 하위 클래스는 상위 클래스 자료형으로 형 변환할 수 있지만, 그 역은 성립 불가

08-03. 메서드 오버라이딩

만약 '일반 고객은 정가를 그대로 지불하지만 VIP 고객은 10%할인은 받을 수 있다.' 는 가정이 생긴다면,

VIPCustomer에서 Customer 클래스의 calcPrice() 메서드를 그대로 사용할 수 없게 된다.

메서드 오버라이딩 : 상위 클래스에서 정의한 메서드가 하위 클래스에서 구현할 내용과 맞지 않을 경우 메서드를 재정의하는 것

알고가자!) 오버라이딩하려면 반환형, 메서드 이름, 매개변수 개수, 매개변수 자료형이 같아야 함

@Override

public int calcPrice(int price) { ... return price - (int)(price * 0.1)  }

 애노테이션 ? 컴파일러에게 특정한 정보를 제공해 주는 역할을 함, 만약 메서드의 선언부가 다르다면 컴파일 오류가 발생하여 개발자의 실수를 막아줌

예) @Override @FuntionalInterface @Deprecated @SuppressWarnings

가상 메서드 : 상속에서 상위 클래스와 하위 클래스에 같은 이름의 메서드가 존재할 때 호출되는 메서드는 인스턴스에 따라 결정됨.

선언한 클래스형 (x) 생성된 인스턴스 (o) 메서드를 호출

알고가자!) 인스턴스가 생성될 때마다 변수는 생성되지만, 메서드는 실행해야 할 명령 집합이므로 여러개 생성되지 않는다. 

일반적으로 메서드를 호출하면 '메서드 영역의 주소를 참조'하여 명령이 실행되는 것이다. 즉, 인스턴스가 달라도 동일한 메서드가 호출된다.

하지만 가상 메서드는 '가상 메서드 테이블'을 만든 후, 각 메서드 이름과 실제 메모리 주소가 짝을 이루고 있다가 테이블의 주소 값을 찾아서 해당 메서드의 명령을 호출하는 원리이다.

재정의된 메서드는 실제 인스턴스에 해당하는 메서드가 호출되고,

재정의되지 않은 메서드는 메서드 주소가 같으며 상위 클래스의 메서드가 호출된다.

// VIPCustomer 인스턴스를 Customer 형으로 변환
Customer vc = new VIPCustomer(10030, "나몰라", 2000)

=> 원래 Customer 형 메서드가 호출되는 것이 맞지만, 가상 메서드 방식에 의해 VIPCustomer 메서드가 호출된다!!

"Do IT! 자바 프로그래밍 입문" 책을 읽고 요약하는 글입니다.

p.232~258

Router는 L3 Switch지만 Host라고도 할 수 있음 (IP도 다 부여, 컴퓨터라고도 할 수 있음)

라우터에 NIC가 여러개 있을 수 있다.

패킷이라는 것이 처리될 때, 라우터 같은 Inline 장치가 어떻게 처리될까?

라우터 내부에서 외부로 통신을 할 때 NIC#1에서 출발하여 IP→TCP→Process→TCP/IP →NIC#2 의 경로를 탈 수 있지만 User모드, Kernel모드, HW를 나누는 경계선을 건널 때마다 waiting 시간이나 CPU를 사용하기 때문에 전산 비용이 비싸진다.

그러므로 NIC#1 ⇒ NIC#2 로 한번에 가도록 하는 HW기반 통신을 하면 ‘가속했다’고 얘기하면서 굉장히 빨라진다.

그런데 NIC#3이 또 있을 수도 있다.

따라서 NIC#1에서 출발하여(=네트워크로 프레임 단위 데이터가 들어와서 패킷 단위로 잘라지든 해서 데이터를 Read했다) IP단에서 처리한 뒤 write를 해야 할 때, NIC#2로 보낼지 NIC#3로 보낼지 인터페이스를 선택을 해야 함

그런데 만약 Read를 했는데 write를 안한다면? 패킷이 필터링되어서 drop이 됨

패킷의 정보를 보고 어디로 보낼지 결정해야 하는데 L3 Switch니까 IP주소를 보고 할 것이다. 그런데 두 개의 NIC 중 적절한 게 없다면 못보내서 Drop되는 경우도 있다.

라우터가 IP단에서 단지처리만 한다면 L3 Switch, Router만이지만, 패킷을 보안적인 측면도 생각해서 처리하면 패킷 단위의 필터링 방화벽이 된다. 필터링을 거쳐서 Bypass 또는 Drop도 하게 되는 것이다.

*Inline 구성이란??

• 인라인 구성은 모든 트래픽이 해당 보안 장비를 물리적으로 거쳐야만 목적지로 전송될 수 있도록 네트워크를 구성한 것을 말한다.
• 상/하단 장비와 동일 대역대에 위치하며 기능을 수행하는 포트에 IP 설정이 필요없는 장비

패킷 단위의 감시대상이 장비를 통과하는 모든 트래픽

• Inbound 트래픽 : 방향성이 내부를 향함. 클 → 서버
• Outbound 트래픽 : 방향성이 외부를 향함. 서버 → 클

Bypass를 하든지 Drop을 하든지 !

출처: (널널한 개발자 TV-네트워크 기본 이론): https://www.youtube.com/playlist?list=PLXvgR_grOs1BFH-TuqFsfHqbh-gpMbFoy 

https://run-it.tistory.com/40

• socket + stream
• TCP + Segment (MSS)
• IP + packet (MTU)
• NIC + Frame
• IP와 Driver 사이에 있는 공간
  • Filter → Filter에서 넘어가면 ByPass, 걸러지면 Drop
  • 필터할 필요가 없다면 Sensor → 항상 ByPass면서 감시하면서 수집, 캡쳐만 함 (예. Npcap 드라이버)
  • Wireshark가 이 캡쳐들을 디코딩함 즉, Analyzer
  • 그런데 만약 카톡을 수집한다면 도감청에 잡혀갑니다. 그런 의미에서 Sniffer라고도 함
  • 그러므로 적법한 목적 상의 수집인지가 중요합니다. 윤리의식 중요!!
• 트래픽이 호스트에서 네트워크쪽으로 나가는 것이 Outbond, 그 반대가 Inbound

출처(널널한 개발자 TV-네트워크 기본 이론): https://www.youtube.com/playlist?list=PLXvgR_grOs1BFH-TuqFsfHqbh-gpMbFoy 

Header + Payload

• Header에서 TCP인지 IP인지 특징 : 20 byte
• Payload
  • MSS (Maximum Segment Size) : 1460 byte
  • MTU (Maximum Transmission Unit) : 1500 byte

• Data : 2^{16} byte (64 KB) 까지 → Total Length가 16 bit 이므로 총 2^{16}가지의 수를 표현할 수 있음

(1KB = 1024Byte)

• IHL (Internet Header Length) : 주로 5 bit
• TOS (Type Of Service) : 대역폭 품질 관리 시 기재
• Identification, Flags, Fragment offset : 단편화와 관련됨
  • MTU가 1400일 때 1500 크기를 보내야 할 때 단편화해서 보내야 하는데
  • 보낼 때 순서를 알아야 하므로 ID가 필요
• TTL (Time To Live) : 패킷이 인터넷에 너무 오래 있어서 버려져야 하는지 여부 알려줌
  • 인터넷에선 라우터라는 거대한 집합체가 패킷을 유통한다. 그 과정에서 문제가 생길 수 있으므로 R→R으로 이동할 때마다 TTL을 1씩 감소시킨다. 그러면 TTL이 언젠가 0이 될 텐데 그때 그 라우터가 패킷을 버린다.
• Protocol : 상위 계층 프로토콜을 가리킴, L4
• Header Checksum : 오류여부 확인

잘 정리된 사이트: https://mindnet.tistory.com/entry/네트워크-쉽게-이해하기-18편-IP-Header-IP헤더-구조

출처(널널한 개발자 TV-네트워크 기본 이론): https://www.youtube.com/playlist?list=PLXvgR_grOs1BFH-TuqFsfHqbh-gpMbFoy 

L2에서는 Mac 주소 (48bit)

네트워크는 한 마디로 switch의 집합체다..!

• NIC
• L2 Access switch ****: PC와 같은 endpoint들이 처음 만나게 되는 switch (방 하나)
• L2 Distribution switch : switch를 위한 switch (건물의 층 하나)
• Router : 전체 PC들의 gateway 역할 (건물 하나)
• Internet
• Uplink : 상위 계층 스위치로 연결됐다는 의미 (L2 Access → L2 Distribution)
• Link-up: 케이블 연결이 딱 됐다는 의미
• Link-down : 연결이 해제됐다는 의미

출처(널널한 개발자 TV-네트워크 기본 이론): https://www.youtube.com/playlist?list=PLXvgR_grOs1BFH-TuqFsfHqbh-gpMbFoy 

UDP 통신이란? 

• User Datagram Protocol, 데이터를 데이터그램 단위로 처리하는 프로토콜
• 비연결형, 신뢰성 없는 전송 프로토콜
• 데이터그램 단위로 쪼개면서 전송해야 하기 때문에 L4, transport Layer

TCP와 UDP가 나온 이유

• IP의 역할은 Host to Host만을 지원한다. 하나의 장비 안에서 수많은 프로그램이 통신해야 할 경우는 IP만으로는 한계가 있다 
  • =>프로세스별 구분 지을 수 있는 Port 번호가 등장하게 됨
• IP에서 오류가 발생하면 ICMP에서 알려준다. 하지만 알려주기만 할 뿐 대처는 못하므로 상위 프로토콜인 TCP와 UDP가 나오게 됐다

ICMP ? 인터넷 제어 메시지 프로토콜. 네트워크 컴퓨터 위에서 돌아가는 OS에서 오류 메시지를 전송받는데 쓰임

TCP와 UDP의 오류 해결법?

• TCP: 데이터의 순차성과 분실, 중복 등을 자동으로 보정해줌으로써 송수신 데이터의 정확한 전달을 보장
• UDP: IP가 제공하는 정도의 수준만을 제공하는 간단한 IP 상위 계층의 프로토콜, 확인 응답을 못하므로 TCP와 달리 에러가 날 수 있고 재전송이나 순서가 뒤바뀔 수 있는 번거로움 존재하며 신뢰도 떨어짐

UDP Header

• Source Port: 시작 포트
• Destination Port: 목적지 포트
• Length: 길이
• Checksum: 오류 검출
  • 중복 검사의 한 형태로, 오류 정정을 통해 자료의 무결성을 보호하는 단순한 방법

UDP는 왜 사용할까?

• 데이터의 빠른 처리, 신속성 때문 !!
• 주로 실시간 방송과 온라인 게임에서 사용됨
• 네트워크 환경이 안 좋을 때, 끊기는 현상을 생각하자

DNS에서 UDP를 사용하는 이유

• DNS Request의 양이 작음 -> UDP Segment에 담길 수 있음
• 3 way handshaking으로 연결을 유지할 필요가 없음 (TCP는 Protocol Overhead가 큼 )
• Request의 손실은 Application layer에서 제어함으로써 신뢰성이 추가될 수 있음 (Timeout이나 재전송 작업을 통해서)
• DNS: port 53번
• 하지만 TCP를 사용하는 경우?
  • Zone Transfer(=DNS 서버 간의 요청을 주고받을 때 사용하는 transter)를 사용해야 하는 경우! 
  • 데이터의 크기가 512바이트(UDP의 제한크기) 를 넘기거나 응답을 못받은 경우

TCP와 UDP 통신 실습

• UDP

UDP server 코드

from socket import *

serverName = "192.168.0.108"
serverPort = 12000
serverSocket = socket(AF_INET, SOCK_DGRAM)
serverSocket.bind((serverName, serverPort)) # 12000 포트로 들어오는 프로세스를 소켓에 바인딩
print("The server is ready to receive")

while True:
    message, clientAddress = serverSocket.recvfrom(2048) # 서버에 들어온 정보를 2kbyte로 계속 읽어들임
    modifiedMessages = message.decode().upper() # 읽어드린 바이트 정보를 str로 변환 후 대문자화
    serverSocket.sendto(modifiedMessages.encode(), clientAddress) # 클라이언트 목적지 주소도 명시해서 보냄

UDP client 코드

from socket import *

serverName = "192.168.0.108"
serverPort = 12000
clientSocket = socket(AF_INET, SOCK_DGRAM) # UDP의 소켓타입=SOCK_DRGAM
message = input("input lowercase sentence")

clientSocket.sendto(message.encode(), (serverName, serverPort)) # 서버의 IP 주소와 port 번호를 명시해서 서버에게 데이터 요청
modifiedMessage, serverAddress = clientSocket.recvfrom(2048)
print(modifiedMessage.decode())

clientSocket.close()

결과

1. UDP는 비연결형 프로토콜로,  데이터 전송 시에 IP 주소와 port 번호를 명시해줘야 한다.
2. sendTo() 메서드를 사용

• TCP

TCP server 코드

from socket import *

serverPort = 12000
serverSocket = socket(AF_INET, SOCK_STREAM)
serverSocket.bind(("", serverPort))
serverSocket.listen(1)
print("The server is ready to receive")

while True:
    connectionSocket, addr = serverSocket.accept() # 요청을 기다리고 받은 후엔 connection 소켓이라는 새로운 분리된 연결을 만듬

    sentence = connectionSocket.recv(1024).decode()
    capitalizedSentence = sentence.upper()
    connectionSocket.send(capitalizedSentence.encode()) # UDP와 달리 connection이 있으므로 목적지 주소가 필요없음

    connectionSocket.close() # 이때 serverSocket은 닫지 않음

TCP client 코드

from socket import *

serverName = "192.168.0.108"
serverPort = 12000
clientSocket = socket(AF_INET, SOCK_STREAM) # TCP의 소켓타입=SOCK_STREAM
clientSocket.connect((serverName, serverPort))
sentence = input("Input lowercase sentence")

clientSocket.send(sentence.encode()) # 서버의 목적지 주소 명시안해도 됨
modifiedSentence = clientSocket.recv(1024)
print("From Server: ", modifiedSentence.decode())
clientSocket.close()

결과

1. TCP는 연결형 프로토콜로, 서버와 클라이언트는 항상 1대1로 연결되어서 통신하므로 따로 명시해줄 필요가 없다.
2. send() 메서드를 사용

참고

https://gyoogle.dev/blog/computer-science/network/UDP.html

(개발자와 네트워크 관리자 모두에게 중요한 개념!★)

• user단의 process가 실행(I/O 혹은 R/W)되면 커널단의 TCP/IP와 디바이스 드라이버를 거치고 NIC를 타고 인터넷으로 연결된다.
• user model application이 TCP에 도달하기 위한 인터페이스가 Socket(=파일의 일종)
• socket의 단위는 stream, 길이는 얼마나 긴지 모름
• stream을 TCP에 보내기 위해 segment로 일정 단위로 댕강댕강 잘라냄
• segment를 한번 encapsulate되면 packet 형식이 되고
• packet이 또 encapsulate되면 frame이 된다.

<패킷의 구성>

• 패킷 하나당 1500byte(MTU, Maximum Transfer Unit)정도
• Header(!송장!)와 Payload(!택배!)로 나뉨

Header는 IP(L3, 20바이트)와 TCP(L4, 20바이트)로 나뉨

payload는 보통 1460바이트가 됨.

⇒ 즉, stream 데이터를 1460바이트씩 끊어내서 Payload로 넣는 것임!

• DPI (Deep Packet Inspection) : payload까지 다 검사하는 것
• encapsulate는 segment를 내용물이라고 한다면 이것을 포장해서 택배박스에 넣는 작업
• frame은 트럭처럼, encapsulate된 패킷들을 다시 encapsulate하는 개념으로 생각하면 됨

출처(널널한한 개발자 TV-네트워크 기본 이론): https://www.youtube.com/playlist?list=PLXvgR_grOs1BFH-TuqFsfHqbh-gpMbFoy 

TCP 통신이란?

- 신뢰성과 순차성을 가진 네트워크 통신 방식

- 신뢰성 없는 네트워크 환경에서 reliable함을 보장

- network congestion avoidance 알고리즘 사용

신뢰성 보장 시 발생가능 문제

1. 손실 : 송수신 시 패킷 손실

2. 순서바뀜: 패킷 순서가 바뀜

3. congestion : 네트워크가 혼잡

4. overload : 수신자 버퍼 용량 초과

흐름제어

- 송수신 간 데이터 처리 속도 차를 해결하기 위한 기법

- 수신측이 송신측보다 처리속도가 느릴 때 문제 발생

- 수신측에서 제한된 용량이 초과 시 데이터가 손실될 수 있으며, 손실된다면 불필요하게 응답과 데이터 전송이 송수신 간에 빈번이 발생하게 됨

🗝 해결법

1. Stop and Wait

- 매번 전송한 패킷에 대해 확인 응답을 받아야만 그 다음 패킷을 전송

2. Go Back N (Sliding Window)

- 수신측에서 설정한 window size (=송신 후 수신까지 동안 전송가능한 패킷의 수)만큼 세그먼트를 송신

- 송신측은 ack 프레임을 받으면 ack 프레임 수만큼 경계가 확장됨

- 송신측에서 ack가 안된 가장 오래된 패킷 번호부터 돌아가서 다시 순서대로 보낸다

혼잡제어

- 송신측의 데이터는 지역망이나 대형 네트워크를 통해 전달된다. 만약 한 라우터에 데이터가 몰릴 경우, 자신에게 온 데이터를 모두 처리할 수 없게 된다. 혼잡이 가중되면 오버플로우나 손실이 발생할 수 있다.

- 따라서 송신측에서 보내는 데이터의 전송속도를 강제로 줄임

- 혼잡: 네트워크 내에서 패킷 수가 과도하게 증가하는 현상

- 혼잡제어: 혼잡현상을 방지하거나 제거하는 기능

🗝 해결법

1. AIMD (Addictive Increase/Multiplicative Decrease)

- 처음에 패킷을 하나씩 보내고 문제가 없으면 window size를 1씩 증가시키며 전송 ws+1

- 전송실패하거나 time-out이 되면 패킷 보내는 속도를 절반으로 줄임  ws*0.5

- 네트워크에 참여한 순서와 관계없이 모든 호스트의 window size가 평행 상태로 수렴하게 되는 특징.

- 문제점: 네트워크의 대역폭이 펑펑 남아도는 상황에도 너무 조금씩 늘리면서 접근하므로, 제대로 된 속도로 통신하기까지 시간이 오래 걸림

2. Slow start

- 처음에 패킷 하나씩 보내고, 문제가 없으면 각각의 ack 패킷마다 window size를 1씩 늘려주기 때문에 한 주기가 지나면 window size가 2배로 된다.  지수함수꼴로 증가

- 혼잡현상 발생 시 window size를 1로 떨어뜨림 -> 혼잡현상이 발생했던 window size의 절반까지는 지수함수꼴로 증가 -> 그 이후는 1씩 증가

3. 빠른 재전송

- 혼잡제어 추가된 정책 중 하나

- 먼저 도착해야 할 패킷이 나중에 도착하더라도 ack 패킷을 보냄

- 단, 순서대로 잘 도착한 마지막 패킷의 다음 패킷 순번을 ack 패킷에 실어서 보내므로, 중간에 하나가 손실되면 송신 측에서 순번이 중복된 ack 패킷을 받게 되고, 이를 감지하는 순간 재전송함

- 중복 패킷을 3번 받으면 재전송 -> 혼잡감지하고 window size를 줄임

- Tahoe는 기본적으로 Slow start를 사용하다가 혼잡이 느껴지면 AIMD로 전환하는데, 빠른 재전송을 처음으로 도입한 방법

4. 빠른 회복

- 혼잡한 상태가 되면 window size를 1로 줄이지 않고 반으로 줄이고 선형증가시킴

- 빠른 회복을 적용하면 혼잡상황을 한번 겪고 나면 순수한 AIMD 방식으로 동작함

- Reno는 빠른 회복을 도입한다.

참고

https://evan-moon.github.io/2019/11/26/tcp-congestion-control/

https://gyoogle.dev/blog/computer-science/network/%ED%9D%90%EB%A6%84%EC%A0%9C%EC%96%B4%20&%20%ED%98%BC%EC%9E%A1%EC%A0%9C%EC%96%B4.html

https://blog.naver.com/winter6120/221000738717

https://goodgid.github.io/Java-JDK-JRE/

어찌저찌 교수님 강의록이랑 구글링 해보면서 실행오류 해결하긴 함!

6장 클래스와 객체2의 연습문제를 풀다보니 저번학기에 들은 데이터베이스 시간에 과제를 했던 게 생각났다. 제공된 요구사항을 바탕으로 ER다이어그램을 만드는 게 과제였는데 어떤 걸 엔티티로 해야 할지 관계로 짜야 할지 계속 고민하다가 눈물 날 뻔한 과제였다. 그래서 어찌어찌 내긴 했는데 교수님께서 올려주신 정답과는 다른 방식으로 짰다...

교수님께선 ER다이어그램을 짜는데엔 정답은 없다고 하셨지만 과연 내가 만든 게 효율적인 답안이었을진...

어쨌든 그 기억이 났다.

콩다방과 별다방을 클래스로 만들어야 하는 건 알겠는데

그다음부턴 어째야 할지 모르겠다

메뉴도 클래스로 만들고 해야하나

객체지향 프로그래밍... 어려운것....

그래도,,,,

뭔가....

재밌는 것,,,,