Rio's 개발일지

디자인 패턴이란 프로그램을 설계할 때 발생했던 문제점들을 객체 간의 상호 관계 등을 이용하여
해결할 수 있도록 하나의 '규약' 형태로 만들어 놓은 것을 의미한다.

싱글톤 패턴 (Singleton Pattern) 이란?

하나의 클래스에 오직 하나의 인스턴스만 가지는 패턴이다.
하나의 클래스를 기반으로 여러 개의 개별적인 인스턴스를 만들 수 있지만,
그렇게 하지 않고 하나의 클래스를 기반으로 단 하나의 인스턴스를 만들어
이를 기반으로 로직을 만드는데 쓰이며, 보통 데이터베이스 연결 모듈에 많이 사용한다.

장점 : 하나의 인스턴스를 다른 모듈들이 공유하며 사용하기 때문에 인스턴스를 생성할 때 드는 비용이 줄어든다.
단점 : 하나의 인스턴스에 대한 의존성이 높아진다는 단점이 있다.

자바스크립트의 싱글톤 패턴
자바스크립트에서는 리터럴 {} 또는 new Object로 객체를 구성하게 되면 다른 어떤 객체와도 같지 않기 때문에
이 자체만으로 싱글톤 패턴을 구현할 수 있다.

싱글톤 패턴은 데이터베이스 연결 모듈에 많이 사용된다.

자바의 싱글톤 패턴

자바로는 중첩 클래스를 이용해서 만드는 방법이 가장 대중적이다. 

** 내부 클래스, 중첩 클래스, 지역 클래스, 익명 클래스에 대해 잘 모르니 추가적으로 공부해서 정리해 놓자.

자바로 구현하는 싱글톤 패턴 7가지

1.  단순한 메서드 호출
싱글톤의 생성 여부를 확인하고 싱글톤이 없으면 새로 만들고, 만들어져 있다면 인스턴스를 반환한다.

하지만 자바는 기본적으로 멀티 쓰레드이기 때문에 우리가 생각한 것 처럼 쓰레드 하나가 종료되야
다음 쓰레드가 들어오게 순차적으로 동작하지 않을 수 있다.

따라서 인스턴스가 싱글톤이 아니라 여러개 생성 될 수 가 있다.

2. synchronized

바로 위 사진에서 원자성 결여를 바로 해결할 수 있는 방법은 메소드인 say에 synchronized를 추가해 Rock를 거는 방법이 있다.

하지만 하나의 인스턴스를 여러 모듈에서 사용하게 되는데 synchronized로 Rock이 걸려있으면 성능에 저하가 발생한다.
가장 단순하게 구현할 수 있는 방법이지만 추천하지 않는다.

그래서 나온 방법이 정적 멤버(static) 이다.

3, 4. 정적 멤버 와 정적 블록

정적 멤버나 블록은 런타임이 아니라 최초에 JVM이 클래스 로딩 때 모든 클래스들을 로드할 때 미리 인스턴스를 생성하는데
이를 이용한 방법이다.
이 방법은 클래스 로딩과 동시에 싱글톤 인스턴스를 만든다. 그렇기 때문에 모듈들이 싱글톤 인스턴스를 요청할 때
그냥 만들어진 인스턴스를 반환하면 되는 것이다.

하지만 정적 멤버 방법은 자원 낭비라는 문제점이 있다.
싱글톤 인스턴스가 필요없는 경우에도 무조건 싱글톤 클래스를 호출해 인스턴스를 만들어야 하기 때문이다.

또한 객체가 없어도 기본적으로 실행되기 때문에 객체 자신 참조인 this 사용이 불가능하고, 정적 블록은 static {} 안에서
초기화 할 수 없다.
정적 static으로 선언시 자바에서 제공하는 가비지 컬렉터 적용을 받지 못하기 어플 종료시까지 자원이 유지되어있어 사용하지 않는다면
낭비가 되는것이다.

5. 정적 멤버와 Lazy Holder(중첩 클래스) ***** 추천 *****

클래스 안에 (예) singleInstanceHolder라는 내부클래스를 하나 더 만듬으로써, Singleton 클래스가 최초에 로딩되더라도
함께 초기화가 되지 않고, 우리가 만든 getInstance() 가 호출될 때 singleInstanceHolder 클래스가 로딩되어 인스턴스를
생성하게 된다.

코드를 보면 중첩 클래스안에 정적 멤버를 넣어 getInstance() 메소드, 즉 인스턴스가 필요한 순간 초기화가 되어
불필요한 자원 낭비를 방지할 수 있다.

6. 이중 확인 잠금 (DCL)

이중 확인 잠금(DCL, Double Checked Locking)는 인스턴스 생성 여부를 싱글톤 패턴 잠금 전에 한번,
객체를 생성하기 전에 한번 체크하여 총 2번 체크하면 인스턴스가 존재하지 않을 때만 잠금을 걸 수 있어
앞서 생겼던 문제점을 해결할 수 있다.

volatile 에 대해 잠깐 설명하자면
자바에서는 쓰레드가 2개 열리면 변수를 메인 메모리(RAM)으로부터 가져오는 것이 아니라
캐시메모리에서 각각의 캐시메모리를 기반으로 가져오게 된다.

따라서 volatile를 적어주지 않으면 변수가 공유되지 않는 각각의 캐시메모리에서 변수를 가져와 무한루프가 발생할 수 있다.

즉, volatile는 변수를 사용하면 값을 캐시메모리에 저장하는 것이 아닌 메인메모리에 저장하겠다는 것이다.

하지만 read / write 와 같이 등록, 수정, 삭제등이 빈번하게 일어나는 상황이라면
모든 값을 메인메모리에서 가져오기에 사용하기 부적합하다.

예를 들면, 여러개의 쓰레드에서 +1 를 요청했는데 모두 값을 메인메모리에서 가져오기때문에
값이 덮어씌워져 원하는 값이 출력되지 않을 수 있기 떄문이다.

7. enum ***** 추천 *****

enum의 인스턴스는 기본적으로 쓰레드세이프(thread safe)한 점이 보장되기 때문에 이를 통해 생성할 수 있다.

싱글톤 패턴의 단점

싱글톤 패턴은 TDD를 할 때 걸림돌이 된다.
싱글톤 패턴은 미리 생성된 하나의 인스턴스를 기반으로 구현하는 패턴이므로

각 테스트마다 '독립적인' 인스턴스 만들기 어려운데 단위 테스트는 테스트가 서로 독립적이어야
테스트를 어떤 순서로든 실행이 가능해 싱글톤 테스트로는 테스트코드 작성에 어려움이 있다.

또한, 싱글톤 패턴은 사용하기가 쉽고 실용적이지만 모듈간의 결합을 강하게 만든다는 단점이 있다.
이때 의존성 주입 을 통해 모듈 간의 결합을 더 느슨하게 만들수 있다.

의존성 주입의 장점과 단점 그리고 원칙

의존성 주입은 모듈들을 쉽게 교체할 수 있는 구조가 되어 테스트하기가 쉽고 마이그레이션하기도 수월하다.
또한, 구현할 때 추상화 레이어를 넣고 이를 기반으로 구현체를 넣어 주기 때문에 애플리케이션 의존성 방향이 일관되고,
애플리케이션을 쉽게 추론할 수 있으며, 모듈 간의 관계들이 조금 더 명확해지는 장점이 있다.

하지만 모듈들이 더욱 많이 분리되므로 클래스 수가 늘어나 복잡성이 증가될 수 있으며 약간의 런타임 페널티가 생긴다.

의존성 주입은 "상위 모듈은 하위 모듈에서 어떠한 것도 가져오지 않아야 한다. 또한 둘 다 추상화에 의존해야 하며,
이때 추상화는 세부 사항에 의존하지 말아야 한다." 라는 의존성 주입 원칙을 지켜주어야 한다.

프로그래밍 패러다임

프로그래밍 패러다임은 프로그래머에게 프로그래밍의 관점을 갖게 해주는 역할을 하는 개발 방법론이다.

프로그래밍 패러다임은 크게 선언형, 명령형으로 나누며,
선언형은 함수형이라는 하위 집합을 갖는다.
또한, 명령형은 다시 객체지향, 절차지향으로 나눈다.

즉, 선언형 프로그래밍은 하위로 함수형 프로그래밍을 가지며,
명령형 프로그래밍은 절차형 프로그래밍과 객체지향 프로그래밍을 가진다.

• 선언형과 함수형 프로그래밍
  선언형 프로그래밍이란 '무엇을' 풀어내는가에 집중하는 패러다임이다.
  "프로그램은 함수로 이루어진 것이다."
  
  함수형 프로그래밍은 '순수 함수'들을 블록처럼 쌓아 로직을 구현하고
  '고차 함수'를 통해 재사용성을 높인 프로그래밍 패러다임이다.
  
  - 순수 함수 : 출력이 입력에만 의존하는 것을 의미한다.
  - 고차 함수 : 고차 함수란 함수가 함수를 값처럼 매개변수로 받아 로직을 생성할 수 있는 것을 말한다.
  
  * 고차 함수를 쓰기 위해서는 해당 언어가 '일급 객체'라는 특징을 가져야 한다.
  
  ** 일급 객체의 특징
  - 변수나 메서드에 함수를 할당할 수 있다.
  - 함수 안에 함수를 매개변수로 담을 수 있다.
  - 함수가 함수를 반환할 수 있다.
  
  
• 객체지향 프로그래밍
  객체지향 프로그래밍은 객체들의 집합으로 프로그램의 상호 작용을 표현하며 데이터를 객체로 취급하여
  객체 내부에 선언된 메서드를 활용하는 방식을 말한다.
  
  ** 객체지향 프로그래밍의 특징
  - 객체지향 프로그래밍은 추상화, 캡슐화, 상속성, 다형성이라는 특징이 있다.
  -- 추상화 : 복잡한 시스템으로부터 핵심적인 개념 또는 기능을 간추려내는 것을 의미한다.
                   사람을 예시로 들었을때 군인, 장교, 키 180, 여친 유무 등 여러가지 특징 중
                   군인, 장교 정도로 뽑아 간추려서 나타내는 것을 이야기한다.
  -- 캡슐화 : 객체의 속성과 메서드를 하나로 묶고 일부를 외부에 감추어 은닉하는 것을 말한다.
  -- 상속성 : 상위 클래스의 특성을 하위 클래스가 이어받아서 재사용하거나 추가, 확장하는 것을 말한다.
  -- 다형성 : 하나의 메서드나 클래스가 다양한 방법으로 동작하는 것을 말한다. (오버로딩, 오버라이딩)
  
  
  
• 설계 원칙
  객체지향 프로그래밍을 설계할 때는 SOLID 원칙을 지켜주어야 한다.
  
  S : 단일 책임 원칙
  O : 개방 - 폐쇄 원칙
  L : 리스코프 치환 원칙
  I : 인터페이스 분리 원칙
  D : 의존 역전 원칙
  
  * 단일 책임 원칙 : 
  단일 책임 웜칙은 모든 클래스는 각각 하나의 책임만 가져야 하는 원칙이다.
  예를 들어 A라는 로직이 존재한다면 어떠한 클래스는 A에 관한 클래스여야 하고 이를 수정한다고 했을 때도
  A와 관련된 수정이어야 한다.
  
  * 개방 - 폐쇄 원칙 : 
  개방 - 폐쇄 원칙은 유지 보수 사항이 생긴다면 코드를 쉽게 확장할 수 있도록 하고
  수정할 때는 닫혀 있어야 하는 원칙이다. 즉, 기존의 코드는 잘 변경하지 않으면서도 확장은 쉽게 할 수 있어야 한다.
  
  * 리스코프 치환 원칙 : 
  리스코프 치환 원칙은 프로그램의 객체는 프로그램의 확장성을 깨뜨리지 않으면서
  하위 타입의 인스턴스로 바꿀 수 있어야 하는 것을 의미한다.
  
  * 인터페이스 분리 원칙 : 
  인터페이스 분리 원칙은 하나의 일반적인 인터페이스보다 구체적인 여러 개의 인터페이스를 만들어야 하는 원칙을 말한다.
  
  * 의존 역전 원칙 : 
  의존 역전 원칙은 자신보다 변하기 쉬운 것에 의존하던 것을 추상화된 인터페이스나 상위 클래스를 두어 변하기 쉬운 것의
  변화에 영향을 받지 않게 하는 원칙을 이야기한다.
  
  
  
• 절차형 프로그래밍 
  절차형 프로그래밍은 로직이 수행되어야 할 연속적인 계산 과정으로 이루어져 있다.
  일이 진행되는 방식으로 그저 코드를 구현하기만 하면 되기 때문에 코드의 가독성이 좋으며 실행 속도가 빠르다.

디자인 패턴이란?
프로그램을 설계할 때 발생했던 문제점들을 객체 간의 상호 관계 등을 이용하여 해결할 수 있도록 하나의 '규약' 형태로 만들어 놓은 것

•  싱글톤 패턴 (singleton pattern)
  싱글톤 패턴은 하나의 클래스에 오직 하나의 인스턴스만 가지는 패턴이다.
  하나의 클래스를 기반으로 여러 개의 개별적인 인스턴스를 만들 수 있지만,
  그렇게 하지 않고 하나의 클래스를 기반으로 단 하나의 인스턴스를 만들어 이를 기반으로
  로직을 만드는데 쓰이며, 보통 데이터베이스 연결 모듈에 많이 사용된다.
  하나의 인스턴스를 만들어 놓고 해당 인스턴스를 다른 모듈들이 공유하며 사용하기 떄문에
  인스턴스를 생성할 때 드는 비용이 줄어드는 장점이 있다.
  하지만 의존성이 높아진다는 단점이 있다.
  
  # 싱글톤 패턴을 구현하는 7가지 방법 (synchronized, static, LazyHolder, DCL, ENUM)
  
  1-1.  단순한 메서드 호출
  싱글톤 패턴 생성 여부를 확인하고 싱글톤이 없으면 새로 만들고 있다면 만들어진 인스턴스를 반환한다.

        1-2. synchronized
         인스턴스를 반환하기 전까지 격리 공간에 놓기 위해 synchronized 키워드로 잠금을 할 수 있다.
         최초로 접근한 쓰레드가 해당 메서드 호출시에 다른 스레드가 접근하지 못하도록 잠금(lock)을 걸어준다.

         이 떄 synchronized 가 지정된 메서드를 호출할 때마다 lock이 걸려 성능이 저하된다.

       1-3, 1-4. 정적 멤버 / 정적 블록
        정적 (static) 멤버나 블록은 런타임이 아니라 최초에 JVM이 클래스 로딩 떄 모든 클래스들을 로드할 떄
        미리 인스턴스를 생성하는데 이를 이용한 방법이다.
        다만, 이 방법은 불필요한 자원낭비라는 문제점이 있다. 싱글톤 인스턴스가 필요없는 경우도 무조건
        싱글톤 클래스를 호출해 인스턴스를 만들어야 하기 때문이다.

     1-5. 정적 멤버와 Lazy Holder (중첩 클래스) **** 추천 ****
      SingleInstanceHolder라는 내부클래스를 하나 더 만듬으로써, Singleton 클래스가 최초에 로딩되더라도
      함께 초기화가 되지 않고, getInstance() 가 호출될 때 singleInstance 클래스가 로딩되어 인스턴스를 생성하게 된다.

       1-6. 이중 확인 잠금 (DCL / 더블 체크 락)
         인스턴스 생성 여부를 싱글톤 패턴 잠금 전에 한번, 객체를 생성하기 전에 한 번 2번 체크하면
         인스턴스가 존재하지 않을 때만 잠금을 걸 수 있기 때문에 앞서 생겼던 문제점을 해결할 수 있다.
         volatile 를 적용하면 캐시메모리가 아니라 메인메모리에서 변수를 공유한다.

         1-7. enum **** 추천 ****
          enum의 인스턴스는 기본적으로 Thread safe 한 점이 보장되기 때문에 이를 통해 생성할 수 있다.

• 싱글톤 패턴의 단점
  
  싱글톤 패턴은 TDD를 할 때 걸림돌이 된다. TDD를 할 때 단위 테스트를 주로 하는데,
  단위 테스트는 테스트가 서로 독립적이어야 하며, 테스트를 어떤 순서로든 실행할 수 있어야 한다.
  
  또한, 싱글톤 패턴은 사용하기가 쉽고 굉장히 실용적이지만 모듈 간의 결합을 강하게 만들 수 있다는
  단점이 있다. 이떄 의존성 주입 (DI) 를 통해 모듈 간의 결합을 조금 더 느슨하게 만들어 해결할 수 있다.

• 팩토리 패턴
  팩토리 패턴은 객체를 사용하는 코드에서 객체 생성 부분을 떼어내 추상화한 패턴이자 상속 관계에 있는
  두 클래스에서 상위 클래스가 중요한 뼈대를 결정하고, 하위 클래스에서 객체 생성에 관한 구체적인 내용을
  결정하는 패턴이다.

• 전략 패턴
  전략 패턴은 정책 패턴이라고도 하며, 객체의 행위를 바꾸고 싶은 경우 '직접' 수정하지 않고 전략이라고
  부르는 '캡슐화한 알고리즘'을 컨텍스트 안에서 바꿔주면서 상호 교체가 가능하게 만드는 패턴이다.

• 옵저버 패턴
  옵저버 패턴은 주체가 어떤 객체의 상태 변화를 관찰하다가 상태 변화가 있을 때마다 메소드 등을 통해
  옵저버 목록에 있는 옵저버들에게 변화를 알려주는 디자인 패턴이다.
  여기서 주체란 객체의 상태 변화를 보고 있는 관찰자이며, 옵저버들이란 이 객체의 상태 변화에 따라 전달되는
  메서드 등을 기반으로 '추가 변화 사항'이 생기는 객체들을 의미한다.
  (주체와 객체를 따로 두지 않고 상태가 변경되는 객체를 기반으로 구축하기도 한다.)

• 프록시 패턴 
  프록시 패턴은 대상 객체에 접근하기 전 그 접근에 대한 흐름을 가로채
  대상 객체 앞단의 인터페이스 역할을 하는 디자인 패턴이다.
  
  이를 통해 객체의 속성, 변환 등을 보완하며 보안, 데이터 검증, 캐싱, 로깅에 사용한다.

• 이터레이터 패턴
  이터레이터 패턴은 이터레이터를 사용하여 컬렉션의 요소들에 접근하는 디자인 패턴이다.
  이를 통해 순회할 수 있는 여러 가지 자료형의 구조와는 상관없이 이터레이터라는 하나의 인터페이스로
  순회가 가능하다.
  
  이터레이터 프로토콜 : 이터러블한 객체들을 순회할 때 쓰이는 규칙
  이터러블한 객체 : 반복 가능한 객체로 배열을 일반화한 객체

• 노출모듈 패턴
  노출모듈 패턴은 즉시 실행 함수를 통해 private, public 같은 접근 제어자를 만드는 패턴을 말한다.
  자바스크립트는 private 나 public  같은 접근 제어자가 존재하지 않고 전역 범위에서 스크립트가 실행된다.
  (난 자바스크립트 잘 모른다 ㅎ...)

• MVC 패턴
  MVC 패턴은 모델 (Model), 뷰(View), 컨트롤러(Controller)로 이루어진 디자인 패턴이다.
  애플리케이션의 구성 요소를 세 가지 역할로 구분하여 개발 프로세스에서 각각의 구성 요소에만 집중해서
  개발할 수 있습니다. 재사용성과 확장성이 용이하다는 장점이 있고, 애플리케이션 복잡해질수록
  모델과 뷰의 관계가 복잡해지는 단점이 있다.
  
  모델
  모델(Model)은 애플리케이션의 데이터인 데이터베이스, 상수, 변수 등을 뜻한다.
  뷰에서 데이터를 생성하거나 수정하면 컨트롤러 등을 통해 모델을 생성하거나 갱신한다.
  
  컨트롤러
  컨트롤러(Controller)는 하나 이상의 모델과 하나 이상의 뷰를 잇는 다리 역할을 하며
  이벤트 등 메인 로직을 담당한다. 또한, 모델과 뷰의 생명주기도 관리하며,
  모델이나 뷰의 변경 통지를 받으면 이를 해석하여 각각의 구성 요소에 해당 내용에 대해 알려준다.
  
  뷰
  뷰는 사용자 인터페이스 요소를 나타낸다.
  즉, 모델을 기반으로 사용자가 볼 수 있는 화면을 뜻한다. 모델이 가지고 있는 정보를
  따로 저장하지 않아야 하며 단순히 사각형 모양 등 화면에 표시하는 정보만 가지고 있어야 한다.
  또한, 변경이 일어나면 컨트롤러에 이를 전달해야 한다.

• MVP 패턴
  MVP 패턴은 MVC 패턴으로부터 파생되었으면 MVC에서 C에 해당하는 컨트롤러가 프레젠터로 교체됐다.
  뷰와 프레젠터는 일대일 관계이기 때문에 MVC 패턴보다 더 강한 결합을 지닌 디자인 패턴이다.
  
  
  
• MVVM 패턴 ( 예 : Vue.js)
  MVVM 패턴은 MVC의 C에 해당하는 컨트롤러가 뷰모델로 바뀐 패턴이다.
  여기서 뷰모델은 뷰를 더 추상화한 계층이며, MVVM 패턴은 MVC 패턴과는 다르게
  커맨드와 데이터 바인딩을 가지는 것이 특징이다.
  
  커맨드 : 여러 가지 요소에 대한 처리를 하나의 액션으로 처리할 수 있게 하는 기법
  데이터 바인딩 : 화면에 보이는 데이터와 웹 브라우저의 메모리 데이터를 일치시키는 기법, 뷰모델 변경 시 뷰 변경

OSI 7계층을 나눈 이유는?

계층을 나눈 이유는 통신이 일어나는 과정을 단계별로 파악하기 쉽고,
특정한 곳에서 이상이 생긴다면 이상이 생긴 단계만 파악해 고칠 수 있기 때문이다.

1. 물리계층 (Physical Layer) / 케이블, 리피터, 허브 등을 통한 데이터 전송

• 7계층 중 최하위 계층
• 주로 전기적, 기계적, 기능적인 (0 , 1) 같은  특성을 이용해 데이터를 전송한다.
• 데이터는 0 과 1 비트열, 즉 On, Off의 전기적 신호 상태로 이루어져 해당 계층은 단지 데이터를 전달한다.
• 즉 데이터가 무엇인지, 어떤 에러가 있는지에 대해서는 전혀 신경쓰지 않는다.
• 케이블이 대표적인 예시이다.

2. 데이터링크 계층 (Data-Link Layer) / 에러검출, 재전송, 흐름제어

• 물리적인 연결을 통하여 인접한 두 장치 간의 신뢰성 있는 정보 전송을 담당한다. (Point-To-Point)
• 따라서 통신에서의 오류도 찾아주고 재전송도 하는 기능을 가지고 있는 것이다.
• 데이터링크 계층에서는 MAC 주소를 가지고 통신하게 된다.
• 데이터링크 계층에서 전송되는 단위를 프레임이라고 하고, 대표적인 장비로는 브리지, 스위치 등이 있다. (여기서 MAC 주소를 사용한다.)

3. 네트워크 계층 (Network Layer) / 주소부여(IP), 경로설정(Route)

• 네트워크 계층에서 가장 중요한 기능은 데이터를 목적지까지 가장 안전하고 빠르게 전달하는 기능 (라우팅) 이다.
• 라우팅 기능을 맡고 있는 계층으로 목적지까지 가장 안전하고 빠르게 데이터를 보내는 기능을 가지고 있다.
• 네트워크 계층의 데이터 전송 단위는 패킷이다.
• 즉, 네트워크 계층은 경로를 선택하고 주소를 정하고 경로에 따라 패킷을 전달해주는 것이 이 계층의 역할이다. (IP주소 사용)
• 네트워크 계층은 라우팅, 흐름제어, 세그멘테이션, 오류제어, 인터네트워킹 등을 수행한다
• 다른 네트워크를 연결해 데이터를 전달함으로써 인터넷이 가능하게 만드는 계층이다.

4. 전송 계층 (Transport Layer) / 패킷 생성 및 전송

• 통신을 활성화하기 위한 계층이다.
• 보통 TCP 프로토콜을 이용하며, 포트를 열어서 응용프로그램들이 전송을 할 수 있게 한다.
• 만약 데이터를 받았다면 전송계층에서 해당 데이터를 하나로 합쳐서 5계층에 던져 준다.
• 전송 계층까지는 물리적인 계층에 속한다 (TCP / UDP 프로토콜을 사용한다.)
• 전송 계층은 특정 연결의 유효성을 제어하고, 일부 프로토콜은 상태 개념이 있고, 연결기반이다.
• 즉, 전송 계층이 패킷들의 전송이 유효한지 확인하고 전송 실패한 패킷들을 다시 전송한다는 것을 뜻한다. (UDP는 아니겟지?)
• 전송계층은 오류검출, 복구, 흐름제어, 중복검사 등을 수행한다.

5. 세션 계층 (Session Layer)

• 데이터가 통신하기 위한 논리적인 연결을 말한다.
• 세션 설정, 유지, 종료, 전송 중단시 복구 등의 기능이 있다.
• 세션 계층은 양 끝단의 응용 프로세스가 통신을 관리하기 위한 방법을 제공한다.
• 동시 송수신 방식, 반이중 방식, 전이중 방식의 통신과 함께, 체크 포인팅과 유휴, 종료, 다시 시작 과정 등을 수행한다.
• 세션 계층은 TCP / IP 세션을 만들고 없애는 책임을 진다.

6. 표현 계층 (Presentation Layer)

• 데이터를 어떻게 표현할지 정하는 역할을 하는 계층이다.
• 표현 계층은 3가지 기능을 가지고 있다.
  1. 송신자에서 온 데이터를 해석하기 위한 응용계층 데이터 부호화, 변화
  2. 수신자에서 데이터의 압축을 풀수 있는 방식으로 된 데이터 압축
  3. 데이터의 암호화와 복호화

7. 응용 계층 (Application Layer)

• 사용자와 가장 밀접한 계층으로 인터페이스 역할을 담당하는 계층이다.
• 응용 프로세스와 직접 관계하여 일반적인 응용 서비스를 수행한다.
• 응용 프로세스 간의 정보 교환을 담당한다.
• ex) 전자메일, 인터넷, 동영상 플레이어 등

쿠키를 삭제하시겠습니까?



HTTP 는 기본적으로 무상태 프로토콜이다.

즉, 서버가 클라이언트의 이전 상태를 보존하지 않는다는 의미이다. (반대의 의미로는 stateful이 있다.)

하지만 서버가 정말로 뭔가를 기억할 필요가 있다면 어떻게 해야할까?

쿠키 (Cookie)

이 문제에 대한 해결책으로, 1994년에 넷스케이프가 쿠키라는 기술을 발명했다.

쿠키는 프로그램 간에 전달되는 작은 정보 조각을 뜻한다.

쿠키는 Key-Value 형식의 문자열 덩어리이다.

즉, 클라이언트가 어떠한 웹사이트를 방문할 경우, 그 사이트가 사용하고 있는 서버를 통해 클라이언트의 브라우저에

설치되는 작은 기록 정보 파일이다.

각 사용자마다의 브라우저에 정보를 저장하니 고유 정보 식별이 가능한 것이다.

쿠키의 기본구조

이후에 브라우저가 같은 서버에 요청을 보낼 때, 브라우저는 그 쿠키를 도로 전송한다.

사실상 서버가 클라이언트 쪽 메모리를 사용하여 클라이언트의 이전 방문에 대한 정보를 기억하는 셈이다.

이 정보는 보통 로그인 상태, 장바구니 내용, 사용자 설정 등이다.

궁금증? 쿠키는 어떻게 만들어진 브라우저 서버을 알아내고, 해당 쿠키만 전송 시킬까?

쿠키 옵션

1. Domain

쿠키 옵션에서 도메인 정보가 존재한다면 클라이언트에서는 쿠키의 도메인 옵션과 서버의 도메인이 일치해야만
쿠키를 전송할 수 있다.

쿠키 옵션에서 도메인은 포트 및 서브 도메인 정보, 세부 경로를 포함하지 않기 때문에 요청해야 할 URL이

https://www.rio0205.tistory.com/user/login/ 이라면
Domain은 rio0205.tistory.com 이 된다.

Domain을 설정하지 않을 경우 브라우저에서 자동으로 도메인 값을 설정한다.

2. Path

서버와 요청의 세부경로가 일치하는 경우 쿠키를 전송

세부 경로란? 서버가 라우팅할 때 사용하는 경로

https://www.rio0205.tistory.com/user/login/ 이라면

/user/login 이 Path 가 된다.

명시하지 않으면 기본으로 / 가 설정된다.

만약 Path 를 /user 로 설정했다면 /user/login 인 경우 즉, 하위 경로까지 쿠키 전송이 가능하다.

cookie.setDomain 의 두가지 형태

-      .rio0205.tistory.com 같이 . 으로 시작되는 경우 관련 도메인에 모두 쿠키를 전송한다. 

-      rio0205.tistory.com 으로 한다면 특정 도메인에 대해서만 쿠키를 전송한다.

이 외에도 여러가지 쿠키 설정이 있다. 해당 부분은 쿠키 관련해서 포스팅 할때 정리해보겠다.

어도비 플래시는 왜 퇴출됐을까?

웹의 초기 설계에서 클라이언트는 단순히 사용자를 대신해서 서버에 요청을 보내고,

폼에 있는 정보를 전송하며, 확장 프로그램의 지원을 받아 특수한 처리가 필요한 사진이나 오디오 같은 콘텐츠를 보여주는 기능을 했다.

하지만 곧 웹에서 코드를 다운로드하여 실행할 수 있게 되었는데 이를 액티브 콘텐츠 라고 부르기도 한다.

액티브 콘텐츠란 ? 

액티브 엑스 컨트롤 (ActiveX) 또는 스크립트 코드로 구성되며 웹 페이지 내에 포함되어 배포되고

클라이언트 컴퓨터 내에 설치되어 동적으로 작동하는 컨텐츠이다.

ActiveX

마이크로소프트 웹브라우저 인터넷 익스플로러에 특화된 기술이다. 다른 브라우저에는 작동하지 않고

악성코드 감염, 보안 취약, 오류, 프로그램 충돌, PC 재부팅 등의 문제가 있어

마이크로소프트 조차 사용 중단을 권하고 있다.

넷스케이프 내비게이터의 초기 버전에는 브라우저 내에서 자바 프로그램을 실행하는 방법이 포함되어 있었다.

그 덕분에 브라우저에서 중요한 연산을 수행할 수 있게 되었고, 어쩌면 브라우저가 워드프로세서나 스프레드시트 같은
기존 프로그램을 대체하고 심지어 운영체제 자체를 대체할 수 있다면 전망을 밝혀주었다.

넷스케이프 내비게이터 는 월드 와이드 웹 (WWW) 의 태동기를 대표하는 웹 브라우저이자 오픈소스 웹 브라우저계에 지대한 공헌을 한
제품이다. 현재에는 파이어폭스로 승계되었다.

~ 잡지식

넷스케이프 내비게이터 가 나오고 사용자들의 반응이 폭발적이여서 약 90%의 시장 점유율을 기록

1995년에 마이크로소프트가 인터넷 익스플로러를 개발하고, 마이크로소프트 윈도우에 포함시켜 무료 배포하면서 점유율 폭락 (윈도우95)

맞대응 했으나 전쟁에서 패배 후 넷스케이프 일부 개발자가 모질라 커뮤니티를 만듬

2002년에 파이어폭스 웹 브라우저 출시

다시 본론으로 돌아와서 

처음 자바가 브라우저에 자바 프로그램을 사용하는 것은 획기적이였으나, 여러 가지 이유로 자바는 브라우저를 확장하는 방법으로는
인기를 얻지 못했다. (마이크로소프트랑 고소하고 난리남)

넷스케이프는 자사 브라우저에서 사용할 새로운 언어를 만들었는데,

바로 1995년에 등장한 자바스크립트이다.

모카 -> 라이브스크립트 -> 자바스크립트 (자바와 구문이 유사한것은 두 언어 모두 C언어의 기본 구문을 바탕으로 하기 때문이다.)

썬 마이크로시스템즈의 자바와 넷스케이프(현재는 오라클꺼)의 자바스크립트는 직접적인 연관이 적다. 

자바와 자바스크립트 모두 가상 머신을 구현해 사용하지만 기술적으로 중요한 차이점이 있다.

자바 소스 코드는 만들어진 곳에서 컴파일되고, 그 결과로 생성된 오브젝트 코드가 브라우저로 보내져 해석되고 (원본소스 알수없음)

자바스크립트는 소스 코드가 브라우저로 보내져 거기에서 컴파일된다. (실행 중이 소스코드를 볼 수 있다.)

오늘날 거의 모든 웹페이지에는 자바스크립트가 어느정도 포함되어있고,

폼에 있는 정보의 유효성 검사, 팝업 창 띄우기, 모니터링에도 널리 사용된다.

하지만 만약 우리가 방문한 웹페이제 브라우저가 직접 처리할 수 없는 포맷의 컨텐츠가 있으면 플러그인을 설치할지 선택할 수 있다.

다른 프로그래밍 언어와 콘텐츠도 브라우저 자체 코드 또는 어도비 플래시 같은 플러그인을 통해 처리된다.

플러그인은 필요에 따라 브라우저에서 동적으로 로드되는 프로그램이다. 

플러그인은 일반적으로 서드파티(외부 개발 업체)가 개발한다.

플러그인을 사용을 선택한다면 우리는 플러그인 코드의 위험 (버그, 행동 모니터링을 할 가능성)을 감수하고 플러그인을 사용할 수 있다.

플러그인을 사용함으로써의 장점은 브라우저에서 실행되는 프로그램으로 더 풍부하고 더 복잡한 콘텐츠를 처리할 수 있다

하지만, 이렇게 하려면 브라우저에서 제 3자가 작성한 확장 프로그램을 실행해야 하는데, 

이 확장 프로그램을 만든사람이 어떤 사람이 알 수가 없다는 것이고

만약 확장 프로램을 만든 사람이 악당이라면 여러분의 컴퓨터는 털린겁니다.

이메일 첨부파일을 함부로 클릭하면 안 되는 이유

액티브 콘텐츠는 웹페이지가 아닌 다른 곳에도 나타날 수 있다.

메일이 왔을 때 메일 프로그램은 텍스트를 표시해야 한다.

그런데 메일에 다른 종류의 콘텐츠가 함께 들어 있을 때 어디까지 처리해야 되는지 문제가 발생한다.

프라이버시와 보안에 큰 영향을 미치기 때문이다.

만약 메일 발신자가 메시지나 수신자에 대한 어떤 정보를 인코딩한 URL을 포함하고 있는 1x1 투명 픽셀 이미지를 포함한다면

이를 막을 방법이 없다. 이러한 보이지 않는 이미지를 웹 비콘(웹 버그)이라고도 한다.

이러한 웹 비콘은 쿠키을 차단하면 일부 기능이나 목적이 실행되지 않을 수 있다.

그렇다면 메일 메시지에 자바스크립트가 포함되어 있다면 어떻게 될까?

워드, 엑셀, 파워포인트가 들어가 있다면?

자동으로 해당 프로그램이 실행되게 해야할까? 메시지의 어떤 지점을 클릭하면 작동하도록 해야할까?

사용자가 직접 링크를 클릭해야 열수 있게 해야할까?

메일 링크는 피해자가 어리석은 일을 하도록 유도할 때 악당들이 가장 선호하는 방법이다.

그리고 PDF 문서는 자바스크립트를 포함할 수 있다.

그렇다면 메일 프로그램에서 자동으로 불러오는 PDF 뷰어가 이 코드를 자동으로 실행해야 할까?

요즘 이메일에는 문서, 엑셀, 발표용 슬라이드, PDF 등을 이메일에 첨부하고 있다.

무턱대고 문서를 클릭하는 것은 바이러스 전파로 이어진다. (.exe 파일을 클릭해서 실행하면 상황은 더 심각..)

출저 : https://lts0606.tistory.com/421

출저 : https://csrc.kaist.ac.kr/blog/2022/01/25/pdf-%EB%AC%B8%EC%84%9C-%EC%A0%95%EC%83%81-pdf-%ED%8C%8C%EC%9D%BC%EB%8F%84-%EC%95%88%EC%8B%AC%ED%95%98%EC%A7%80-%EB%A7%88%EC%84%B8%EC%9A%94/

출저 :  

https://inpa.tistory.com/559#comment9172763

HTTP란?

HTTP는 HyperText Transfer Protocol의 약자로, 인터넷에서 하이퍼텍스트 문서인 HTML로 만든 웹페이지를 전송하기 위해 사용되는
프로토콜입니다.

즉, HTTP는 웹 브라우저와 웹 서버가 통신하는 절차와 형식을 규정한 것입니다.

HTTP 통신은 반드시 웹 브라우저의 요청이 있어야 시작됩니다.

HTTP 메시지

응용 계층의 데이터 단위는 메시지(Message)입니다. 

HTTP 메시지는 서비스를 제공하고 이용하기 위해 어플리케이션이 만든 데이터에 헤더를 붙여 캡술화한 것입니다.

헤더에는 각 계층에 적용되는 프로토콜이 데이터를 처리하여 계층의 역할을 수행할 때 필요한 정보가 담깁니다.

모든 HTTP 메시지는 시작 줄로 시작합니다.

HTTP는 실제 어플리케이션이 주고받는 데이터를 HTTP 헤드와 구별하여 HTTP 본문 또는 HTTP 바디라고 합니다.

한마디로 서버가 클라이언트에게 전송할 데이터가 담겨 있는 부분 HTTP 바디입니다.

따라서 HTTP 메시지는 HTTP 헤드와 HTTP 본문으로 구성됩니다.

HTTP 헤드와 HTTP 본문은 빈 줄(Black line)인 공백 라인으로 구분합니다.

공백 라인으로 요청과 응답에 관한 모든 정보가 전송되었음을 알려주는 것입니다.

REFRENCE

https://better-together.tistory.com/149

WAS (Web Application Server) 란 ?

웹 서버와 웹 컨테이너의 기능을 모두 수행하는 프로그램을 말한다.

웹 서버란?

• 간단히 이야기하면 클라이언트 요청에 응답을 보내는 컴퓨터 프로그램을 말한다.
  이 데이터는 HTML 형식을 데이터이거나, 각종 리소스(자원)이다.

하드웨어 / 소프트웨어 적 웹 서버

• 하드웨어 측면 :
  1. 웹사이트의 컴포넌트 파일들을 저장하는 컴퓨터
  2. 컴포넌트 파일에는 html 문서/ images / css / js 파일 등
  3. 이 컴포넌트 파일들을 최종 소비자의 디바이스에 전달한다.
  4. 웹 서버는 인터넷에 연결되어 있고, 도메인 이름을 통해 접속될 수 있다.
  
• 소프트웨어 측면 : 
  1. 웹 사용자가 어떻게 호스트 파일들에 접근하는지를 관리
  2. HTTP 서버는 URL(Web address)과 HTTP의 소프트웨어 일부이다.

웹 컨테이너 란?

웹 컨테이너는 클라이언트의 요청에 따른 데이터를 데이터베이스에서 전달받아 웹 서버로 전달하는 프로그램이다.

웹 컨테이너의 기능

• 프로그램 실행 환경과 데이터베이스 접속 기능을 제공한다.
• 여러 개의 트랜잭션을 관리한다.
• 업무 처리를 위한 비지니스 로직을 수행한다.
• Web Service 플랫폼의 역할을 수행한다.

즉, 웹 서버 측에서 클라이언트의 요청을 받아 응답할 때, 요청에 필요한 데이터를 처리하거나 웹 서버에 전달해 주는 역할을 한다.

때문에 데이터베이스 서버와 같이 작업을 수행하는 경우가 많다. 일종의 중간관리자로 웹 서버를 지원하는 역할이라고 보면 된다.

이런 소프트웨어를 미들웨어(Middleware)라고 한다.

WAS의 개념

aws는 DB 조회나 다양한 로직 처리를 요구하는 동적인 컨텐츠를 제공하기 위해 만들어진 Application Server 이다.

HTTP를 통해 컴퓨터나 장치에 애플리케이션을 수행해주는 미들웨어(소프트웨어 엔진)이다.

WAS의 역할

WAS = Web Server + Web Container

• WAS 는 Web Server 기능들을 구조적으로 분리하여 처리하고자하는 목적으로 제시되었다.
• 분산 트랜잭션, 보안, 메시징, 쓰레드 처리 등의 기능을 처리하는 분산 환경에서 사용된다.
• 주로 DB 서버와 같이 수행된다.

• 현재 WAS가 가지고 있는 Web Server도 정적인 컨텐츠를 처리하는 데 있어서 성능상 큰 차이가 없다.

WAS의 주요기능

• 프로그램 실행 환경과 DB 접속 기능 제공
• 여러 개의 트랜잭션(논리 작업 단위) 관리 기능
• 업무를 처리하는 비즈니스 로직 수행

그렇다면 WAS가 Web Server의 기능도 모두 수행하면 되지 않을까?

• 기능을 분리하여 서버 부하 방지
  1. WAS는 DB 조회나 다양한 로직을 처리하느라 바쁘기 때문에 단순한 정적 컨텐츠는 Web Server에서 빠르게 클라이언트에 제공되는 것이 좋다.
  2. WAS는 기본적으로 동적 컨텐츠를 제공하기 위해 존재하는 서버이다.
  3. 만약 정적 컨텐츠 요청까지 WAS가 처리한다면 정적 데이터 처리로 인해 부하가 커지게 되고, 동적 컨텐츠의 처리가 지연됨에 따라
  수행 속도가 느려진다.
  4. 즉, 이로 인해 페이지 노출 시간이 늘어나게 될 것이다.
• 물리적으로 분리하여 보안 강화
  1. SSL에 대한 암복호화 처리에 Web Server를 사용
• 여러 대의 WAS를 연결 가능
  1. Load Balancing을 위해서 Web Server를 사용
  2. fail over(장애 극복), fail back 처리에 유리
  3. 특히 대용량 웹 어플리케이션의 경우(여러 개의 서버 사용) Web Server와 WAS를 분리하여 무중단 운영을 위한
  장애 극복에 쉽게 대응할 수 있다.
  4. 예를 들어, 앞 단의 Web Server에서 오류가 발생한 WAS를 이용하지 못하도록 한 후 WAS를 재시작함으로써
  사용자는 오류를 느끼지 못하고 이용할 수 있다.
• 여러 웹 어플리케이션 서비스 가능
  1. 예를 들어, 하나의 서버에서 PHP Application과 Java Application을 함께 사용하는 경우
• 기타
  1. 접근 허용 IP 관리, 2대 이상의 서버에서의 세션 관리 등도 Web Server에서 처리하면 효율적이다.

즉, 자원 이용의 효율성 및 장애 극복, 배포 및 유지보수의 편의성을 위해 Web Server와 WAS를 분리한다.
Web Server를 WAS 앞에 두고 필요한 WAS들을 Web Server에 플러그인 형태로 설정하면 더욱 효율적인 분산 처리가 가능하다.

References

https://gmlwjd9405.github.io/2018/10/27/webserver-vs-was.html

클라이언트  - 서버 기반 프로그램 동작 방식

클라이언트는 처리할 데이터가 있으면 네트워크를 통해 서버에 전달하고, 서버가 처리한 결과를 네트워크를 통해 다시 받아

결과를 화면에 출력하는 역할만 합니다.

1.  먼저 처리할 데이터를 입력 받아 서버에 처리를 요청하면
2.  서버는 화면에서 입력한 데이터를 전송 받아 처리합니다.
3.  그런 다음 계산 결과를 웹 브라우저로 전송하여 결과를 보여줍니다.

즉, 웹 기반 프로그램의 경우 사용자가 사용하는 프로그램의 기능이나 화면이 바뀌면 서버에서 모두 처리합니다.

클라이언트 - 서버 기반 프로그램과 마찬가지로 클라이언트가 특별히 수행해야 할 작업이 없습니다.

그리고 모든 기능을 서버에서 처리하므로 보안 면에서도 월등히 우수합니다.

웹 기반 프로그램은 관리하기 용이할 뿐 아니라 보안 면에서도 탁월하여 널리 사용되고 있습니다.

여기서 한 발 더 나아가 JSP가 ASP, PHP 같은 웹 기술을 더하고 데이터베이스 연동 기능을 추가한다면

실시간으로 클라이언트의 요청을 처리할 수도 있습니다.