network : 동일한 프로토콜을 사용하는 디바이스들의 집합
device : 네트워크에 연결해서 어떤 서비스를 이용하거나 제공할 수 있는 것들을 총칭
networking : 네트워크에 연결된 디바이스들 간의 데이터 전송
packet : 헤더와 바디로 구성된 데이터 단위
OSI 7 계층 : application / presentation / session / transport / network / data link / physical
레이어(계층 구조)를 사용할 때 장점 : 표준을 설정함으로써 어떤 장비라도 상호 정보 처리가 가능하게 되었으며 네트워크의 프로토콜을 분리함으로써 프로토콜이 단순해졌고 따라서 관리가 쉬워지고 훨씬 더 유연한 구조가 되었다.
인터넷 프로토콜
- IP : 네트워크 계층에 존재하는 프로토콜. 신뢰성이 없는 프로토콜이다. 트랜스포트 계층에서 패킷을 안전하게 전달하는 책임진다는 가정을 바탕으로 데이터를 효율적으로 전송하는 것에만 집중한다.
- TCP : 신뢰성이 있는 프로토콜. 데이터는 발신자가 보내는 것과 같은 순서로 수신자에게 전달된다. 소켓과 포트를 이용해서 동시에 여러 개의 접속을 지원할 수 있다.
- UDP : 신뢰성이 없는 프로토콜. 속도가 빠르다. 비연결지향 프로토콜
인터넷 어플리케이션 프로토콜
- Telnet : 원격지 컴퓨터에 access하기 위한 프로토콜로서 TCP 포트 23번을 사용한다. 개발자, 시스템 관리자들이 원격에서 개발중인 시스템을 관리하거나 업데이트할 때 주로 텔넷을 이용한다.
- FTP : 파일을 효율적으로 전송하기 위해 만들어진 표준 프로토콜 .TCP 포트 20번 사용
- POP3 : 이메일을 수신하기 위한 표준 프로토콜. 메일 서버가 사용자를 대신해 이메일을 수신하고 그 내용을 보관한다. TCP 포트는 110번. C/S 프로토콜이다
- IMAP : 로컬 컴퓨터에서 이메일에 접근하기 위한 표준 프로토콜이다. POP3와 유사한 C/S프로토콜이다. POP3와 차별된 점은 사용자가 메일의 제목과 송신자만을 보고 실제로 메일을 내려받을 것인지를 결정할 수 있다. 또한 사용자가 메일 서버에 폴더나 우편함을 만들거나 관리할 수 있다. TCP 포트는 143번
- SMTP : 메일을 보내고 받는 데 사용되는 프로토콜. 그러나 수신측에서의 큐 메시지 능력의 제한으로 인해 수신할 때는 POP3나 IMAP중 하나를 쓰는 것이 일반적이다. TCP 포트는 25번
- HTTP : 클라이언트에서 서버로 접속해서 요청을 하면 서버에서는 클라이언트가 요청한 정보에 대해서 적절한 응답을 하고 접속을 끊어버린다. TCP 포트는 80번
- Finger : 메일 주소를 이용해서 특정 유저에 관한 정보를 알려주는 데 사용하는 프로토콜이다. 어떤 유저가 현재 자신의 시스템에 로그인한 상태인지, 또는 가장 최근에 로그인했던 세션과 그 컴퓨터에 있는 유저에 관해 유지되고 있는 데이터에 따라 여러 정보를 말해줄 수 있다. 보안상의 이유로 주로 핑거의 접근을 막는다. TCP 포트는 79번
소켓과 포트
- 소켓에는 어플리케이션을 위한 한 쌍의 데이터 큐가 있다. 전송을 위한 큐와 수신을 위한 큐다. 소켓은 보통 운영체제의 커널 안에 있는 메모리 영역으로 구현되고 특정 포트 하나와 연결해서 어플리케이션과 통신하게 된다.
- 포트란 이미 정해진 번호이며 16비트 값으로 나타낸다. 1~1024번까지는 대부분 예약되어 있기 때문에 1024이상의 포트번호를 사용해야 한다.
보안
- 해킹, 바이러스 등으로부터 자산을 보호하는 것
- 방화벽 : 외부로부터 내부 정보망을 보호하기 위한 네트워크 구성요소 중 외부망과 통하는 유인한 창구로써 외부의 침입을 막는 하드웨어 및 소프트웨어를 말한다.
- 방화벽 시스템에 등록된 IP 주소만 접근이 가능하도록 관리하는 일종의 선택적 차단막이다.
Thread
- 프로세스 : 자기 자신만의 주소 공간을 갖는 독립적인 실행 프로그램
- 스레드 : 프로세스 내의 독립적인 순차흐름 또는 제어 / 경량 프로세스
- 하나의 프로세스는 한 개 이상의 스레드로 수행된다.
어떤 경우에 쓰레드를 사용해야 하는가?
- 하나의 실행흐름만을 가지고 있는 서버(싱글스레드 서버)가 있다고 가정할 때 처음 접속한 사용자는 자신의 요청이 바로 처리되므로 문제가 되지 않는다. 그러나 앞서 요청한 사용자의 요청이 아직 완전히 처리되지 않았다면 그 뒤에 요청한 사용자들은 앞선 요청이 끝나기만을 기다려야 한다. 이런 경우 스레드를 사용해서 서버에 접속한 각 사용자의 요청 거리를 별도의 실행흐름으로 처리한다면 속도가 훨씬 빨라질 것이다.
- 스레드는 동시에 실행될 수 있는 또 다른 실행흐름을 갖게 함으로써 좀더 효율적인 작업을 하게 해주며 이렇게 병렬로 처리할 수 있어서 서버 프로그램 등 대부분의 경우 어플리케이션의 성능과 효율을 향상시켜준다는 장점이 있다.
- 이미지 프로세싱처럼 CPU 사용률이 높고 오랜 시간이 걸리는 작업에 멀티스레드를 사용하면 오히려 성능이 저하된다.
스레드의 생성과 시작
- Thread 인스턴스를 생성하고 start() method로 Thread 인스턴스를 실행시킨다. 그 후 run() method의 모든 처리가 끝나면 바로 해당 Thread 인스턴스가 소멸된다.
Thread 생성자 : Thread(ThreadGroup group, Runnable target, String name, long stackSize)
- name : 각 스레드의 고유 이름
- stackSize : 각 스레드 객체는 자신만의 고유 스택을 갖는데 그 크기를 지정하는 것이다. 구현된 JVM마다 어떤 로직을 처리하기 위해 필요한 메모리 크기가 다르기 때문에 스택사이즈를 지정할 때는 매우 주의해야 한다.
White-box & black-box
- 디자인 패턴에서는 상속을 통한 재사용을 white-box reuse라고 하고 합성을 통한 재사용을 black-box reuse라고 한다.
- 어떤 객체를 상속하면 private으로 선언되지 않은 모든 변수와 메소드, 생성자가 하위클래스에 노출된다. 하위클래스에서 수퍼클래스의 내부가 보인다는 의미로 white-box라 한다.
- 상속의 장점은 오버라이딩을 통해 수퍼클래스의 구현을 손쉽게 재정의할 수 있다. 그러나 상속을 이용해서 재사용할 때 단점이 세 가지가 있다.
- - 하나는 수퍼클래스가 하위클래스에 불필요하게 많은 부분이 노출된다는 것이다. 이것은 객체지향의 원칙 중 하나인 캡슐화에 위배되고 또한 하위클래스가 수퍼클래스의 구현에 종속되고, 수퍼클래스 구현이 변경되어야 할 경우가 생기면 하위클래스도 변경해야 하는 문제점이 발생할 수 있다.
- - 또 다른 하나는 컴파일 시점에 객체의 형식이 이미 결정된다는 것이다. “A 클래스가 B 클래스의 수퍼클래스다” 라는 식의 정보가 이미 컴파일 시점에 결정되어 버리기 때문에 런타임 시점에서 상속받은 수퍼클래스의 구현을 변경 할 수 없어 시스템의 유연성이 떨어진다는 단점이 생긴다.
- - 마지막 하나는 시스템이 진화(evolution) 할수록 상속 관계가 복잡해져서 그 시스템의 상속 트리를 정확하게 이해하고 있지 않으면 시스템의 수정과 확장에 손을 댈 수 없는 상황까지 발생할 가능성이 생기기 떄문이다.
- 캡슐화란 하나의 클래스를 블랙박스화하는 것이다. 즉, 클래스 안의 데이터에 해당하는 필드는 모두 private으로 선언해서 외부에서 직접 접근할 수 없게 만들고 외부에는 public으로 선언된 메소드(인터페이스)만을 공개하는 것이다. 이렇게 어떤 클래스의 내부 데이터를 감춰놓고 외부에서는 오직 해당 클래스에서 제공하는 public 메소드(인터페이스)로만 그 객체의 내부 데이터를 변경 또는 제어할 수 있게 만드는 것을 캡슐화라고 한다.
- 캡슐화에서 중요한 것은 “다른 클래스에서 어떤 클래스의 기능을 사용할 때 그 내부 구현에 대해 전혀 몰라도 된다”는 것이다.
- Composition(합성)은 객체가 다른 객체의 참조자를 얻는 방식으로 런타임 시에 동적으로 이뤄진다.
- 합성에도 오용에 따른 단점과 주의해야 할 점이 존재한다. 객체 간의 관계가 수평 관계가 되기 때문에 큰 시스템에서 많은 부분에 걸쳐 합성이 사용될 때 객체나 메소드명이 명확하지 않으면 코드의 가독성이 떨어지고 이해하기 어려워지게 된다. 따라서 합성을 사용할 때에는 그 용도에 따라 클래스들을 패키지로 적절하게 분리해야 하고 각각의 사용 용도가 명확하게 드러나도록 인터페이스를 잘 설계해야 한다.
'java framework > network' 카테고리의 다른 글
nifi를 이용한 kafka에서 elasticsearch로 data 전송 (0) | 2019.08.02 |
---|