반응형

Go function? Go Method?

Go 에서 function 을 만들거나 Method 를 만들 때, 이게 Go 에서 function 인지 Method 인지 헷갈려서 글을 올립니다.

Go 에서는 보통 개발자가 알고 있는 function 이 function 이고, 구조체에 추가한 동작을 Method 라고 합니다.

반응형

'Golang > Let's Go' 카테고리의 다른 글

Go memory 사용량 확인  (0) 2023.12.13
Go 1.21에서 추가된 slice 의 기능  (0) 2023.11.04
BindJSON vs ShouldBindJSON  (0) 2023.10.12
Go 변수와 상수  (0) 2023.10.01
Go 에러로 인한 서버 다운 막는 방법  (0) 2023.08.28
반응형

Protocols

Protocols 는 3 가지의 categories 에 해당됩니다.

  1. Legacy Protocols: Legacy Protocols 은 이메일 클라이언트, 캘린더 및 웹 서비스에 연결할 때 앱에서 필요한 기본 인증(사용자 이름과 암호)을 사용합니다.
  2. HTTP-Based Protocols: 요청-응답 프로토콜인 HTTP 는 사용자가 클라이언트와 서버 간에 하이퍼텍스트 메시지를 전송하여 HTML 파일과 같은 웹 리소스와 상호 작용할 수 있게 합니다.
  3. Modern Protocols: 일반적으로 오픈 소스이며 아직 널리 지원되지 않는 현대 프로토콜은 선도 기술로, 이전 비디오 스트리밍 프로토콜이 겪었던 일부 문제를 해결합니다.

 

9 가지의 protocols 는 아래와 같습니다(주관적으로 잘 사용되지 않은건 자세한 내용을 안 적었습니다).

  1. HTTP Live Streaming(HLS)
    • HTTP-Based 입니다.
    • HLS 는 m3u8 과 ts 를 호출합니다.
    • m3u8 은 재생할 목록에 대한 호출입니다.
    • ts 는 대상 media 파일에 대한 호출입니다.
    • ts 파일은 MPEG-2 TS(Transport Stream) 파일입니다. 또한 디지털 방송을 위한 데이터 전송 규격입니다.
    • 장점
      • 호환성: HLS 프로토콜은 사실상 모든 인터넷 연결 장치 및 운영 체제에 대한 스트리밍에 적합합니다.
      • 보안: HLS 는 안전한 스트리밍으로 알려져 있습니다.
      • 품질: HLS 는 적응 비트레이트 스트리밍 (ABR) 기술을 활용하여 초고화질 비디오 스트림을 생산합니다."
    • 단점
      • 지연 시간: HLS 는 다른 선호되는 프로토콜들만큼 낮은 지연 시간을 유지할 수 없어 영상 품질이 낮아집니다.
      • 부실한 입력: HLS 는 입수(ingest)에 가장 적합한 선택지가 아니며, HLS 호환 인코더가 접근 가능하거나 비용 효율적이지 않기 때문입니다.
  2. Dynamic Adaptive Streaming over HTTP (MPEG-DASH)
    • MPEG 는 Moving Pictures Expert Group 입니다.
    • Open-source 입니다.
    • 어떤 오디오 또는 비디오 코덱에도 매우 맞춤화 할 수 있습니다.
    • 비트레이트 스트리밍을 지원합니다.
    • HTTP-Based 입니다.
    • 장점
      • 적응성: 이 프로토콜은 ABR을 활용하여 다양한 인터넷 속도와 조건에서 고품질 비디오 스트리밍을 제공합니다.
      • 맞춤 설정: MPEG-DASH 는 오픈 소스로, 사용자가 독특한 스트리밍 요구 사항을 충족시키기 위해 사용자 정의할 수 있도록 합니다.
    • 단점
      • 제한된 호환성: MPEG-DASH 는 Apple 기기 또는 iOS 와 호환되지 않아 방송의 범위를 제한합니다.
      • 퇴화: 이 프로토콜은 한때 매우 인기가 있었지만, 그 한계로 인해 다양한 다른 고급 프로토콜 옵션들과 공정하게 경쟁하기 어렵습니다.
  3. WebRTC(Web Real-time communications)
    • 실시간 지연 시간으로 비디오 스트림을 시청자에게 전달하는 오픈 소스 프로젝트입니다.
    • P2P (peer-to-peer) 스트리밍을 기반으로 한 저지연 스트리밍 솔루션입니다.
    • Modern Protocol 입니다.
    • 장점
      • 유연성: WebRTC 는 오픈 소스로, 개발자들은 특정한 스트리밍 요구 사항을 충족시키기 위해 사용자 정의할 수 있는 충분한 유연성을 가지고 있습니다.
      • 실시간 지연: WebRTC 는 실시간 지연으로 스트리밍을 지원하며, 이는 방송된 비디오가 고품질의 비디오로 실시간으로 시청자 화면으로 전송됨을 의미합니다.
    • 단점
    • 제한된 지원: WebRTC 비디오 스트리밍 프로토콜은 웹 표준으로서 최근 채택되었을 뿐입니다. 시장은 이 스트리밍 설정과의 호환성 문제에 부딪힐 수 있으므로 엔지니어들은 이에 적응하는 데 시간을 더 필요로 할 수 있습니다
  4. Real-Time Messaging Protocol (RTMP)
    • Adobe 가 개발한 기존의 프로토콜로, 스트리밍 서버와 Adobe Flash Player 간에 오디오 및 비디오 파일을 전송하는 데 사용됩니다.
    • 최종 사용자에게 전달되기 전에 RTMP 을 통해 스트리밍 플랫폼으로 전송됩니다.
    • Legacy Protocol 입니다.
    • 장점
      • 낮은 지연: RTMP 는 실시간 비디오 스트림이 안정된 연결을 유지하도록 보장하여 인터넷 연결이 불안정한 경우에도 뷰어에게 안정성을 제공합니다. 뷰어는 또한 인터넷 연결이 안정화되면 스트림을 쉽게 재개할 수 있습니다.
      • 적응성: 이 프로토콜의 스트림 피드는 적응형이며 RTMP 서버에 호스팅되므로 뷰어는 피드의 일부를 건너뛰거나 되감거나 또는 시작된 후에 라이브 스트림에 참여할 수 있습니다.
      • 유연성: 개발자는 RTMP 프로토콜을 사용하여 오디오, 비디오 및 텍스트와 같은 다양한 비디오 형식을 하나의 일관된 패키지로 통합할 수 있습니다. 이것은 또한 여러 미디어 채널을 활용할 수 있도록 하며, 오디오의 경우 MP3 및 AAC, 비디오의 경우 MP4, FLV 및 F4V와 같은 형식으로 스트리밍할 수 있습니다.
    • 단점
      • 제한된 지원: Flash 는 빠르게 구식이 되고 있으며, HTML5 플레이어가 그 자리를 대체하고 있습니다. 현재 Flash 는 RTMP 를 지원하며 이 프로토콜은 HTTP 기반 비디오 프로토콜과 같은 컨버터 없이는 HTML5 플레이어에서 재생할 수 없습니다. 낮은 대역폭: RTMP 스트림은 대역폭 문제에 취약하여, 빈번한 라이브 스트림 중단으로 사용자 경험에 부정적인 영향을 미칠 수 있습니다
  5. Real-Time Streaming Protocol (RTSP)
    • 엔터테인먼트를 대상으로 개발된 기존 프로토콜로, 주요 사용 사례는 엔드포인트 간의 TV 및 영화와 같은 미디어 세션을 설정하고 제어합니다.
    • 라이브 스트리밍 데이터를 단독으로 전송할 수 없으며 RTSP 서버가 RTP 및 기타 프로토콜과 협력하여 스트리밍 작업을 수행해야 합니다.
    • 저지연 스트리밍을 지원하지만 대부분의 기기와 브라우저와 호환되지 않습니다.
    • Legacy Protocol 입니다.
    • 장점
      • 세그먼트 스트리밍: 뷰어는 비디오를 완전히 다운로드하지 않고도 내용을 시청할 수 있으며, RTSP 스트림을 통해 다운로드가 완료되기 전에 내용을 시청할 수 있습니다.
      • 매우 맞춤화 가능: 전송 제어 프로토콜 (TCP) 및 사용자 데이터그램 프로토콜 (UDP)와 같은 다른 프로토콜을 활용하여 자체 비디오 스트리밍 애플리케이션을 만들 수 있습니다.
    • 단점
      • 인기 부족: RTSP는 이 목록의 다른 프로토콜들보다 훨씬 인기가 적으며, 대부분의 비디오 플레이어와 스트리밍 서비스는 RTSP 스트리밍을 지원하지 않습니다.
      • HTTP 호환성 없음: RTSP를 직접 HTTP로 스트리밍할 수 없으므로 웹 브라우저에서 RTSP를 스트리밍하기 쉬운 방법이 없습니다. RTSP는 비즈니스 내의 보안 카메라와 같은 사설 네트워크에서 비디오 스트리밍을 위해 설계되었지만, 개발자들은 웹사이트에 이 프로토콜을 사용하여 스트리밍하기 위해 추가 소프트웨어를 임베드하는 옵션을 가지고 있습니다.
  6. Transmission Control Protocol (TCP)
    • 월드 와이드 웹 (HTTP), 이메일, 파일 전송 프로토콜 (FTP) 등과 같은 핵심 인터넷 응용 프로그램에서 광범위하게 사용됩니다.
    • 긍정적인 확인과 재전송 (PAR)을 통해 신뢰성을 제공합니다.
    • RTMP, RTSP, HLS 및 MPEG-DASH와 호환됩니다.
    • Internet Protocol 입니다.
    • 장점
      • 매우 신뢰성 높음: 목적지 라우터에 데이터 전달을 보장하여 신뢰성 있는 프로토콜입니다.
      • 오류 제한: 플로우 컨트롤 및 데이터 확인을 사용하여 네트워크 에러를 체크하는 메커니즘을 제공합니다. 데이터 패킷이 수신자의 IP 주소로 순서대로 도착하지 않거나 일부가 누락되더라도, 프로토콜은 각 조각이 있어야 하는 위치로 도착하도록 보내는 발신자와 통신합니다.
    • 단점
      • 속도가 느림: 데이터 패킷의 재정렬과 재전송으로 인해 TCP는 전송 속도가 느립니다.
      • 번거로운 프로토콜: 데이터를 보내기 전에 소켓 연결을 설정하기 위해 TCP는 데이터 전송 전에 세 개의 패킷을 필요로 합니다
  7. User Datagram Protocol (UDP)
    • 최소한의 메커니즘을 갖춘 연결 없는 프로토콜입니다.
    • 대량의 클라이언트로 데이터를 전송하는 데 이상적입니다.
    • 비스 검색 및 브로드캐스팅을 위한 멀티캐스트 지원을 제공합니다.
    • 재전송 지연이 낮아 실시간 음성 통화 (VoIP), 온라인 게임 및 실시간 비디오 스트리밍과 같은 응용 프로그램에 적합한 선택입니다.
    • SRT, WebRTC, RTSP 및 RTP와 호환됩니다.
    • Internet Protocol 입니다.
    • 장점
      • 속도: 데이터가 도착 순서대로 처리되기 때문에 무결성은 도착 시점에 체크섬을 사용하여 확인되므로 UDP는 빠릅니다. 가벼운 프로토콜: UDP는 연결 추적, 메시지 순서 지정 등이 없기 때문에 가벼운 프로토콜로 간주됩니다.
      • 연결 없음: UDP는 연결을 기반으로 하지 않으므로 한 프로그램이 동시에 다른 프로그램으로 여러 패킷을 보낼 수 있습니다.
    • 단점
      • 불정확성: UDP 스트리밍을 통해 전송된 데이터 패킷은 누락되거나 순서가 뒤바뀔 수 있으며, 이로 인해 라이브 스트림 중에 몇 프레임이 누락되거나 오디오에 경미한 일시적인 오류가 발생할 수 있으며, 이는 사용자 경험에 영향을 미칠 수 있습니다.
      • 기본 오류 확인: 기본적인 오류 확인을 수행하고 오류 복구 시도 없이 잘못된 패킷을 삭제합니다.
  8. Secure Reliable Transport (SRT)
반응형
반응형

BindJSON vs ShouldBindJSON

BindJSON 은 확인해보면 *http.Request 를 사용하는 것을 확인할 수 있습니다. 그렇기 때문에 error 가 발생할 때 Request status code 가 400으로 변경되고 content-type 이 text/plain; charset=utf-8 로 변경됩니다. 이러한 점 때문에 ShouldBindJSON 사용을 권장하기도 합니다.

근데 테스트나 글 찾아보면 ShouldBindJSON 은 http.request 를 건들지 않는다고 하는데, Binding interface 까지 가보면 결국 BindJSON 과 같이 *Context.Request 를 호출해서 사용하는 걸 확인할 수 있습니다.

정확하게 문제에 대해서 이야기 한 사람 내용 입니다.

[이슈 설명] 현재, 함수 ctx.Bind, ctx.BindJSON, ctx.BindQuery는 모두 ctx.MustBindWith를 사용합니다. 제 의견으로는 현재의 ctx.MustBindWith의 구현에는 다음과 같은 단점이 있습니다. 이것은 이미 이전에 논의되었으며 여러 문제와 스레드를 크롤링하지 않기 위해 여기에 포함시킴을 양해 부탁드립니다.

  1. 제어 부족
    • HTTP 상태 코드를 400으로 설정하며 개발자는 다른 HTTP 상태 코드(ex: 422, http.StatusUnprocessableEntity)를 설정할 수 없습니다.
    • 이것은 핸들러 체인을 중단합니다. 개발자는 결과 오류를 중단할 가치가 있는지 또는 조화될 수 있는지 결정할 수 있어야 합니다.
    • Bind JSON 및 Query에서 논의한대로 반복된 Bind를 사용할 수 없습니다. 개발자는 쿼리 매개변수와 JSON 본문을 별도로 바인딩하고 싶을 수 있습니다.
  2. 가능한 잘못된 Content-type 헤더
    • Content-type을 text/plain으로 설정합니다.
    • ctx.JSON 또는 수동으로 콘텐츠 유형 헤더를 설정하려 해도 도움이 되지 않습니다. 대신 다음과 같은 경고가 표시됩니다: [GIN-debug] [WARNING] Headers were already written. Wanted to override status code 400 with 422

[제안] 역호환성을 유지하기 위해 기존 바인드 방법의 동작을 변경할 수 없습니다. 따라서 이 PR은 ShouldBind 대응 항목을 추가합니다 - ctx.ShouldBind, ctx.ShouldBindJSON, ctx.ShouldBindQuery.

Readme 파일은 아직 업데이트하지 않았으며 여기서의 토론 결과에 따라 업데이트할 것을 제안합니다. readme의 모든 예제를 Should 동등 항목을 사용하도록 전환하는 것을 제안합니다. readme에 있는 모든 예제는 ShouldBind 방법을 사용하도록 업데이트되었습니다. 또한 Bind와 ShouldBind 방법의 차이를 설명하는 섹션을 추가했습니다.

참조

반응형

'Golang > Let's Go' 카테고리의 다른 글

Go 1.21에서 추가된 slice 의 기능  (0) 2023.11.04
Go function? Go Method?  (0) 2023.10.12
Go 변수와 상수  (0) 2023.10.01
Go 에러로 인한 서버 다운 막는 방법  (0) 2023.08.28
Golang 속도 측정 방법  (0) 2023.08.28
반응형

Go 변수와 상수

상수는 Go 키워드 const 를 사용하여 선언합니다.

const c int = 10

const (
	v = "Vista"
	ma = "Master"
	a = "Amend"
)

//상수값을 0부터 순차적으로 부여하기 위해 iota 라는 identifier 를 사용할 수 있습니다.

const (
	v = iota //0
	ma //1
	a //2
)

 

Go 키워드로는 break, default, func, interface, select, case, ... 가 있습니다.

//특정 case 의 문장을 실행한 뒤 다음 case 의 문장을 실행하고 싶을 때는 fallthrough 키워드를 사용합니다.
//단, 맨 마지막 case 에는 fallthrough 키워드를 사용할 수 없습니다.
fallthrough
i := 3

switch i { //값을 판단할 변수 설정
case 4: //각 조건에 일치하는
	fmt.Println("4 이상") //코드를 실행합니다.
	fallthrough
case 3: // 3과 변수의 값이 일치하므로
	fmt.Println("3 이상") //이 부분을 실행
	fallthrough //fallthrough를 사용했으므로 아래 case를 모두 실행
case 2:
	fmt.Println("2 이상") //실행
	fallthrough
case 1:
	fmt.Println("1 이상") //실행
	fallthrough
case 0:
	fmt.Println("0 이상") //실행, 마지막 case에는 fallthrough를 사용할 수 없음
}
반응형

'Golang > Let's Go' 카테고리의 다른 글

Go function? Go Method?  (0) 2023.10.12
BindJSON vs ShouldBindJSON  (0) 2023.10.12
Go 에러로 인한 서버 다운 막는 방법  (0) 2023.08.28
Golang 속도 측정 방법  (0) 2023.08.28
Go smtp SendMail 기능 구현(기본 구현과 개선)  (0) 2023.08.24
반응형

Schema 생성 방법

 

> go run -mod=mod entgo.io/ent/cmd/ent new Schema

> go generate ./ent
반응형

'framework > entgo' 카테고리의 다른 글

DB Table을 가지고 Schema 자동 생성  (0) 2023.08.30
반응형

DB Table을 가지고 Schema 자동 생성

** 참고하지만 실제 시도는 아래 순서 따라 진행: https://entgo.io/he/blog/2021/10/11/generating-ent-schemas-from-existing-sql-databases/#getting-started**

 

 

실행 순서

  1. ent schema 폴더와 generate.go 파일 생성
    go run -mod=mod entgo.io/ent/cmd/ent new

  2. entimport 설치
    go run -mod=mod ariga.io/entimport/cmd/entimport -h

  3. DB에 따라 다르게 입력
    ** 여기서 만약 table에 primary key가 없으면 에러가 발생하며 schema를 생성해주지 않습니다. primary key를 생성하면 작동합니다. **
    mysql: go run ariga.io/entimport/cmd/entimport -dialect mysql -dsn "root:pass@tcp(localhost:3306)/entimport"
    postgreSQL: go run ariga.io/entimport/cmd/entimport -dsn "postgres://tuba_om_user:Okestro2018\!@10.10.10.135:5432/tuba_om?sslmode=disable" -tables "vt_event, vt_event_rule" -schema-path "./"

  4. table .go 가 schema 폴더 아래 잘 생성이 되었으면 아래 코드를 작동
    go generate ./ent
반응형

'framework > entgo' 카테고리의 다른 글

Schema 생성 방법  (0) 2023.08.30
반응형

Go 에러로 인한 서버 다운 막는 방법

golang은 에러가 발생하면 서버가 다운됩니다. 서버 다운을 막기 위해 try-catch가 있으면 좋지만 golang은 없기 때문에 다른 방법을 찾아봤습니다.

해결 방안으로는 defer 와 panic + recover를 사용했습니다.

 

 

코드

func test() {
	client, err := db.Open("", "")
	
	defer func() {
		client.Close()
		if r := recover(); r != nil {
			//에러 처리
		}
	}()
	
	if err != nil {
		panic(err)
	}
}
반응형

'Golang > Let's Go' 카테고리의 다른 글

BindJSON vs ShouldBindJSON  (0) 2023.10.12
Go 변수와 상수  (0) 2023.10.01
Golang 속도 측정 방법  (0) 2023.08.28
Go smtp SendMail 기능 구현(기본 구현과 개선)  (0) 2023.08.24
Zero allocation  (0) 2023.08.10
반응형

Golang 속도 측정 방법

 

코드

startTime := time.Now()

elapsedTime := time.Since(startTime)
fmt.Printf("실행시간: %s\n", elapsedTime)
반응형

'Golang > Let's Go' 카테고리의 다른 글

Go 변수와 상수  (0) 2023.10.01
Go 에러로 인한 서버 다운 막는 방법  (0) 2023.08.28
Go smtp SendMail 기능 구현(기본 구현과 개선)  (0) 2023.08.24
Zero allocation  (0) 2023.08.10
Go 패키지 외부 공개 여부  (0) 2023.08.09

+ Recent posts